A blog by Gary Bernhardt, Creator & Destroyer of Software

The Value of Continuous Processes

29 Oct 2009

Consider the construction of software:

  • Bad: create a big design, then turn it into code.
  • Better: create a small design, then turn it into code, then stop and ponder it.
  • Best [1]: design software in the shortest iterations possible – on the order of minutes – with failing tests as your guide.

Consider the construction of tests:

  • Bad: write a lot of code, then test it before a release.
  • Better: write some code, then test it at the end of the (1- or 2-week) iteration.
  • Best: write code and tests together, ensuring that all tests pass at all times.

Consider the construction of companies:

  • Bad: have an idea, write a business plan, get funded, hire a team of 10, build the product, release it.
  • Better: have an idea, build the simplest version that could possibly work, validate it in the market.
  • Best: have an idea, validate it in the market without writing any code

Consider the construction of products:

  • Bad: collect requirements, generate specifications, build software, release it when it's "done".
  • Better: talk to customer, generate story cards, build software, release it every two weeks.
  • Best: ???

One of these things is not like the others. The first three processes above deliver value faster, more consistently, and with less risk as they become continuous. Why shouldn't this be true of the entire product cycle?

This is why I'm excited about (1) Kanban and (2) continuous deployment. I think you should be too. Consider it carefully, because so far the score card shows that processes become more effective as the cycles get tighter, and we surely have a lot farther to go.

[1]: "best" is defined here as "best that I know of."