Could You Use Software Development Insurance?

If you could buy an insurance policy on your software development deliverables, would you?

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

Regression testing
Automated build & deploy
A smoke testing plan
Experienced/specialized developers and testers
Code documentation

These insurance measures have either high costs or low benefits. Regression testing tends to take a long time and be done manually, so it’s infrequent. 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 consider unit tests a quality measure: by the time the code gets to QA, it’s already in good shape, so the testers 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 disaster.

If they cause a regression, they’ll know pretty quickly what they broke.
They can contribute usefully outside of their areas of expertise.
They can experiment with alternative solutions and constructs, instead of sticking to one idea.
They can improve design without the nagging doubt, “What else did we have to change?”
“Crazy” bugs (remember the Mars Rover incident?) are less likely.
They can change or enhance functionality, 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 be part of a coherent test strategy. And they must be effective; you can’t just have any tests (so be very careful trusting AI to generate them!)

This matter requires team alignment. Experience shows that when every developer proceeds with their own understanding, the sum total makes for poor insurance even if coverage metrics are high.

The best insurance on software development has always come from extensive use of test-driven development (TDD). This is now truer than ever: if the team uses AI to write some of the code without using TDD, their insurance policy will provide false security.