Technical Debt

Process Balance

The "Process Folks" need to walk fine lines of balance in the world of software application development, IMHO...

While process is good, it is not an end-all. In factory work, Taylorism-based processes can be very valuable. In knowledge work, they can be very stifling and counter-productive. For so long, folks have tried to break up software development into factory-like chunks of processes. If you have that kind of software work, then automate it with a tool, not a human . Otherwise, much of what we do -- be it creative or inventive or engineering -- needs a much looser set of processes. The smallest amount to ensure "Done Means Done" -- and to the right degree of "-illity". Which is no small feat to express just how good a design needs to be, just how much flexibility is needed, how much maintainability, just what is quality code, balancing ROI of time spent getting code out and time in the users hands for getting feedback sooner, etc.

Striking the balance is part of the engineering mindset; but this requires good inputs from many sources, including stakeholders, marketing, users, architects, business folks, infrastructure, tech support, QA, etc.

SCRUM Mistress

Okay, so there are lots of complaints about SCRUM MASTER certifications being handed out like expensive candy. But is that really what the complaint is about?

Or, is it something else?

1. Scrum, being primarily about simple techniques for managing a project, maybe really does only take two days to master? (Which I think is believable.)
2. Quite possibly, most of the dissent and gnashing of teeth could be around *assuming* mastering scrum means that developing a working software application naturally follows?

#2 does, quite frankly, involve a whole (heck of a) lot more than the world's best scrum master.

Gardening

Building an application is a lot like gardening, or better, farming.

Are you doing a quick app (maybe a flower pot), or a mission-critical app -- where you need sustainable farming techniques?