I’ve been reading “Math with Bad Drawings” by Ben Orlin and am currently reading through the insurance portion — how insurance works, what makes it profitable, and the like. The gist (if you sell insurance professionally, forgive my butchering of your product) is that people pay insurance to protect them if Something Bad happens, and that Bad Thing is a thing that actuaries have spent their careers (or more) figuring out the probability of happening.
In short, if there’s a 1% chance a herd of cats will wreak havoc on a banana crop, you can buy Cats Destroying Bananas insurance for some price that will cost more than that 1% chance divided by their risk pool. That way, as long as Cats Destroying Bananas doesn’t become a regular occurrence, the insurance company will be profitable.
There’s probably a good reason
insurance companies don’t provide software project insurance (if you
know of a company that does, I would love to have more details), and
that’s because we (the buyer of insurance) know that software projects
fail regularly. We have more knowledge about software projects than your
average insurance actuary, and that gives us a leg up.
The thing is, if we’re so ready and willing to buy software insurance because we know it’d pay out; why aren’t we equally likely to pay for training to ensure the project is delivered on time and on budget?
If you would pay 10% of your budget for insurance to compensate you if the project didn’t get delivered on time, would you also pay 10% of your budget to deliver it on time?
Using TDD to deliver a project from start to finish is a lot like buying software project insurance. It’s going to pay for itself from the buyer’s perspective. There are lots of reasons why teams don’t adopt TDD (not the least of which is that it’s not taught in a way that makes it conducive to every day use), but for the teams that adopt TDD and stick with it, they’ve purchased insurance that will net them a positive return.
Of course, I should note that “Go do TDD” is neither helpful nor going to make your team successful on its own. There are lots of ways to learn TDD and they all seem to avoid addressing the problems project teams face when trying TDD. I’m taking a different approach in my course. It’s geared towards solving the problems project teams face head-on. You can sign up to receive more details about the course and receive a subscriber’s only discount that won’t be available anywhere else by going to course.doubleyourproductivity.io.