Not seeing the value in unit testing is a little like not seeing the difference between sticker price and total cost of ownership. #TDD - @btgrant

This tweet got me thinking. As software developers we frequently struggle to convince the business side of the need for Test-Driven Development and other technical debt eradication strategies. I think this tweet makes a great analogy.

When we buy a car, we typically start by narrowing the field of options based on our price range. From there we try to maximize features, which can include anything from fuel economy to seat coolers. One feature that some people ignore more than others in their car shopping is maintenance costs.

Suppose you’re about to buy your next car. There’s one feature you really want but it would raise the cost by 20%. You don’t want to live without this feature- say it’s seat coolers and you live in Houston. You might really want your next car to have seat coolers if you live in Houston. I lucked into a rental car with seat coolers in Texas once, in the summer, and I was quite pleased.

So maybe you choose to pay more than you can really afford. That’s not unusual at all in this day and age. But let’s say that’s not an option. Maybe you’ve already learned your lesson on that one.

But you are resolute that you must have seat coolers. So what’s a poor consumer to do? Well, you might browse Craigslist and find exactly what you want, other than the color is likely not your first choice. Sure, it has high mileage, a nebulous title history, and smells a little bit like mold. The important thing is it has seat coolers and everything else you wanted. You don’t have to compromise at all!

Or do you? You wanted seat coolers and you wanted them now. You probably would have paid more for a more solid version of the car if you had the money for it but you simply didn’t. And you simply couldn’t go without cold seats. And you couldn’t wait to save up for it.

Well, you might learn later on that your new car was totaled in a hurricane. And then you might find yourself paying a lot more than you expected in maintenance and related costs: repairs, fear of road trips, rental cars, tows, and absolute hatred from your mechanic for making them deal with mold and all kinds of issues that are difficult to fix and even more difficult to diagnose. In fact, your mechanic will probably double or triple their rate whenever they see your car being dragged into their shop again.

If you’re in the software world, this might sound familiar. Just replace “car” with “application” and “seat coolers” with “overdue must-have feature”.

When we can’t compromise on time or cost, quality suffers. When quality suffers, total cost of ownership increases. Quality means far more than “works as expected with a snappy user interface”. High quality implies high maintainability, which implies low cost of ownership.

Time and cost are obvious, in-your-face decision factors. Quality is more nebulous. Unfortunately, this makes it too easy to compromise in a way that will haunt everyone involved for the entire lifetime of the product. I understand that sometimes you really can’t wait and you really can’t pay more and so quality must suffer. If nothing else, I hope this post helps you go into these decisions with your eyes wide open so you can understand and plan for the impact.