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.