The code freeze is killing the dinosaurs

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.