« Google Maps | Main | SCO and Canopy »
Running Code and Regular Releases
Several interactions I’ve had recently with groups building Web applications have led me a renewed appreciation for the power of running code in a development project. Both of these organizations were some time into a large development project and still didn’t have running code and regular, consistent release cycle. This wisdom gets great lip service, so it surprises me to see people who should know better not following it.
- Any development project, but particularly those for the Web, ought to plan to release running code that someone (even just the QA group) can hit, exercise, and start to profile.
- The initial system might be nothing more than a loop and some placeholder presentation, but it should be there as soon as possible after the project starts.
- There should be a regular cycle of releases and engineers ought to be held accountable for supporting the release with working code, even if its not feature complete. For production system, regular might mean once a week. For code in development, it might be nightly.
- The discipline that supports the release, like bug tracking systems and release engineering, ought to be built into the project from the start. Building that discipline is as important as building the project.
Doing this gets engineers used to the discipline and gives everyone the ability to see their code contributing to the final system on a regular basis. This is crucial for motivating ownership and accountability. Until you have code running that everyone can see, all you have is a dream—no matter how many pieces you have compiled and sitting on hard drives.
Posted by windley on February 10, 2005 4:53 PM
Comment from Steve Loughran at February 11, 2005 2:46 AM
I agree that regular releases build discipline, but in my experience, having to support that live systemthat QA/external customers start using can distract you into firefighting. That is, the pressure to do a just-now-fix on the code overwhelms the need to do the right fix, and can make it pretty stressful.
To cope you need to have a rule that it always takes overnight to roll out an update (lie, say it is the automated deploy process).
Comment from Isaac Gouy at February 11, 2005 11:59 AM
"The wisdom"
1a) Releasing a protoype when only 20% of the functionality is complete, was a significant predictor of both reduced defect-rate and increased productivity.
1b) Both formal design reviews and regression tests were significant predictors of reduced defect-rate (but not productivity).
1c) Daily builds were a significant predictor of increased productivity (but not reduced defect-rate).
1d) There was no significant association between either defect-rate or productivity, and dividing a project into subcycles (which developed a subset of the final functionality).
Conclusion: Get a prototype into the hands of customers asap.
http://www.cc.gatech.edu/classes/AY2005/cs6300_fall/papers/maccormack
2a) One-third of the variation in product quality was explained by how quickly customers were given the first beta version.
2b) The data showed no relationship between the final product quality and the number of beta releases.
Conclusion: "Get a low-functionality version of the product into customers' hands at the earliest possible stage..."
http://www.sloanreview.mit.edu/smr/issue/2001/winter/6/