July 13, 2006

...Learn TDD with Codemanship

Bug Fixes Stay Fixed

A very viable alternative to heavyweight processes is simple principles, regardless of the size of your development organisation or the systems they're creating. Take Linux, for example. There is no "Team Linux", or an official "Unified Linux Development Process". Linux - and much of Open Source software - is developed according to very simple rules that you must never break. The rule that when you check your changes into a shared codebase, the code must still work, for example. If you have broken anything, then your changes will be rejected and the codebase will be rolled back to how it was before. You can follow any development process you like, just as long as you don't break the code when you check your changes in. Simple.

Another very powerful principle you can employ is this:

Bug fixes stay fixed

It's an all too common tale of woe: the beleagured development team frantically fixing bugs near the release date, and with every fix they inject at least one new bug - often more than one - which means even more bug fixing. When you try running up the down escalator you tend to burn a lot more energy.

It's a metric I strongly recommend every team captures. How many times do they have to fix the same bug during the lifetime of the system? The answer should be exactly one.Once its fixed, it should never darken our door again.

But how do we achieve this? Quite simply any way you like. (My preferred method is to write an automated test that reproduces the bug, so if it ever reappears you can fix it straight away and nobody need ever know...)
Posted 15 years, 1 month ago on July 13, 2006