Building on yesterday’s improvement about recording all problems and using that to drive process change, I’m looking at an even bigger picture today.
I was discussing Agile/Lean methodologies with someone this morning and started to think about the “perfect” development process. This was also driven by Patrick McKenzie’s post How (And Why) To Release Hourly, Not Yearly.
To me, the ideal development process would have the analyst’s detailed design documents directly drive automated tests. Then, if every test passes, the build gets deployed to the production environment. As much of the process as possible would be automated (you can replace “automated” with “foolproof”, if you are so inclined).
It’s scary, but there are companies that have managed to set up an environment that includes continuous deployment.
In order to test this out, I’m going to have to start with a thin slice of an application. A web app that uses a database seems like the most complex scenario (at least, until you start talking about server farms).
This weekend, I’m going to map out the steps needed to build this ideal process. It will probably take months to really implement everything, since I expect there are several problems without obvious solutions. But without pushing to the edge, I won’t find out where the limits truly are.
This should work similar to the Lean principle of “lowering the water to expose the rocks”.