The code freeze is killing the dinosaurs

extinct dinosaur photo
Reptilian dinosaurs died out when the earth got too cold.

Software dinosaurs are dying now because they have code freezes.

The software development process for most companies has a flow – gather requirements, design, implement, test, release. There can be feedback loops, iterative cycles, spirals or waterfalls, but they all have these steps. When teams “freeze the code” and submit to test, they are creating their own mini-ice age and dooming themselves to extinction.
Steps in a dinosaur’s development process

  1. Receive list of requirements/features for the current release.
  2. Implement the code for the release.
  3. Check the code into source code control.
  4. Freeze the code and deliver to the test team.
  5. Receive defect reports from test team.  (see Where bugs come from for more background)
  6. Fix all defined defects. Return to step 3 until no bugs are reported.

Steps in a mammal’s development process

  1. Receive list of requirements/features for the current release.
  2. Implement a subset of the code for the release.
  3. Build the solution (using an automated build system)
  4. Run the automated test suite. Return to step 2 for this feature and rewrite until no bugs are found.
  5. Return to step 2 for each piece of code until all code is complete.

Why the dinosaurs lose

The dinosaurs work without any feedback until they hope they are done. They don’t know if the code is good until the test team reviews it. They know it compiles. That’s not the same thing. Reptilian dinosaurs had tiny little brains, of course they froze. Software dinosaurs don’t have the same excuse.

  • Dinosaurs create more bugs. Software can be very interdependent. Bugs in one part of the code can cause, or even worse, obscure bugs in other parts of the code. The longer the release cycle, the more tangled code there is, and the bigger the problem. The larger the dev team, the more tangled code there is, and the bigger the problem. Dinosaurs introduce more bugs because of it.
  • Dinosaurs spend more money on testing. Dinosaurs work inefficiently, stumbling over, working around, or obliviously coding in the presence of bugs that they’ve introduced. Only after the test team tells them do they know they’ve messed up. This is a linear process. Code – test – recode – retest – repeat. Imagine that the test team finds 10 bugs. The dinosaurs then attempt to fix them. In the process of fixing them, they create another bug. The test team retests, the dinosaurs rework, and the cycle continues until an acceptable defect rate is achieved (it may be “no bugs found”). These extra test cycles cost money.
  • Dinosaurs take longer to deliver. The dinosaurs are waiting while the test team tests. The test team is waiting while the dinosaurs code and recode. The release cycle is longer because the process is linear.

Why the mammals win

  • The mammals have automated their build process.
  • They use automated testing.
  • They only check in code if it passes all the tests (this is the definition of maintaining a release-ready state).

Automated build and test allows mammals to avoid creating entanglement-related bugs by testing all code before it gets checked in to source control (and becomes official, shareable code). This results in fewer bugs.

The mammals have tested every step of the way – they don’t need to freeze the code at the end and test it. This saves time in the process.

There’s a great post at James Shore’s blog about automating build and test as part of achieving a release-ready state.

We also wrote about the evolution of the software development process.

2 thoughts on “The code freeze is killing the dinosaurs

  1. This article sounds great if we are working in an ideal world, but there are several exposures:

    1) At least GUI automation testing requires script creation/maintenance AFTER the new code is created.

    2) There is some testing that is hard (or even impossible) to automate.

    3) It may not be cost efficient to automate everything.

    4) Manual testing often yields more complexity and diversity with regards to testing (google Exploratory Testing).

    5) Manual Testing also produces more of a “user experience” giving a better sense of user acceptance and a broader view of the app.

    Anyway, I feel in most cases that it is important to have some mix of automation and manual testing to be most successful.

    After all, don’t both reptiles and mammals eat bugs? :)

  2. Jim, thanks for reading, and for the comments!

    I completely agree with your point that there is stuff that is impractical to test in an automated fashion (impossible, not justified, etc). I absolutely agree that a mixture of testing is appropriate, and varies from extremely automated to extremely manual – depending on the application’s purpose, design, and goals.

    The most important thing is that the development team shouldn’t hide in a cave and write code until they think they are done, but rather incorporate testing iteratively throughout the process.

    Bricklayers check the level of each row of bricks as they go, and correct any problems as soon as they appear – they don’t wait until the entire wall is finished to discover that they are an inch out of level.

    Great zinger with the the bug-eating!

    And thanks again, please – keep it coming and keep me honest.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.