Could You Use Software Development Insurance?

Like most people, I carry various kinds of disaster insurance. If I crash my car, I’ll get paid back its worth. If my house burns down, I will lose lots of personal effects and time, but not my financial investment.

Even if the law or mortgage lenders didn’t require car/home/life insurance, I would still buy them. They are a large expense but they have a huge benefit: They allow me to live my life without fear of financial ruin.

If you could buy a policy on your software development efforts, guaranteeing some quick recovery if anything goes horribly wrong, would you?

Let’s consider popular kinds of insurance you might already be carrying:

Regression testing
An automated build
Developers who are experts in some components
A smoke testing plan
Guru developers and testers who can do very specialized tasks
Code documentation

These insurance measures have either high costs or low benefits. Regression testing, often done manually, takes a long time and is often hampered by time pressure. The disadvantages of siloing developers are well-known. Builds and smoke testing provide only rudimentary information.

Nevertheless, you can pay for software development insurance: It takes the form of comprehensive automated developer testing (a.k.a. unit testing or microtesting).

Most people perceive unit tests as a quality measure: By the time the code gets to testing, it’s already in good shape, so QA can spend their time more usefully. That is correct, but not enough.

When teams have enough unit tests, which they can run quickly and frequently, that is insurance: It allows them to develop software without fear of ruin.

They can improve design without the nagging doubt, “We’re not sure we didn’t break something.”
They can experiment with alternative solutions and constructs, instead of sticking to one idea.
They can write useful code in areas outside of their expertise.
If they do break something, they’ll know pretty quickly exactly what they broke.
“Crazy” bugs (remember the Mars Rover incident?) are less likely.
They can embrace changes and new features, because the tests show at all times exactly what the existing functionality does.
Bug fixes can be properly designed and integrated into the code rather than patched (“Be careful, don’t change too much there!”)

For this to work, you have to have enough unit tests. They must also be properly done and maintained, so their cost remains fixed and doesn’t get out of hand. You can learn from me how to do that, and you can also find books.

Like all insurance, you have to buy just enough and for the right perils. Your team must have a clear understanding of its risks and its automated testing strategy. If every developer proceeds with his or her own best understanding, that won’t make for good insurance for the team.

Lastly, the insurance metaphor only goes so far. Automated developer testing (especially when done using test-driven development) has at least another half-dozen benefits. It simplifies design, documents as-built code, helps you write less code, makes certain development tasks more interesting, and more. But that’s for another day.