Your Software Sucks

Part of my job is to consult with companies about how to improve ROI from their software investments. The conversations themselves are straightforward. Have your teams write unit tests and incorporate Test-Driven Development. Invest in quality up-front. Build Acceptance Criteria into your features and user stories. I suggest, in other words, the same kinds of techniques that have been part of the grab-bag of Extreme Programming for the past twenty years. I tell them what books to read, what blogs to follow. My clients listen politely. They are, after all, paying me for my advice. They nod. They agree. And then they go back to business as usual, which is spitting out unmaintainable software at an unsustainable rate of speed.

And I have always been left with one burning question: why?

It hurts my ego a little when they do this, but I handle this because that’s what I’m paid to do. Go ahead, hurt me plenty. I’m a big boy. I can take it.

But there’s another part of me that has never been able to rationalize the way the business world writes code. Quite simply, we churn and burn our developers like boiler-room salespeople set loose on a new offer of penny stocks. I have seen the damage that results from code built this way. When Boeing’s 737 Max fleet crashes out of the sky, or when thousands of Toyotas suddenly accelerate out of their drivers’ control, or when hackers break into a top credit bureau and make off with millions of SSNs and related financial records, I tend to shrug. These are not unpredictable catastrophes; they are a direct result of how we have chosen to build and maintain software.

I have also seen—and written—software constructed with an eye to quality. I remember dreading a simple maintenance task on an unfamiliar codebase. When I pulled up the code, it was so clearly and concisely written it practically gleamed. My task, which on sloppier code could easily have taken two days, was done in less than an hour. I made a point of praising the code’s owner to management. Clean code is a rare treat.

I also remember when I was given leeway to use a strict test-first approach to develop a mission-critical system. The resulting module ran in production for years without any defects. Maintaining this code was a dream come true. I could simply ignore it, secure in the knowledge that it tested itself thoroughly every time it compiled. #NoDefects works. I’ve seen it work first-hand.

When you’re tempted to think that “quality just happens,” remember that Toyota’s embedded code had more than ten thousand global variables. And some managers lived with that code base. No doubt those managers thought their developers were good at their jobs, so of course they would take the time to produce quality work. Or at least work that was good enough.

And because they didn’t, and because nobody was checking, because apparently nobody cared, people died.

It’s like Aragorn says in Lord of the Rings: “Are you scared?... Not nearly enough. I know what hunts you.”