How To Not Die By A Thousand Cuts. Or, How To Think About Software Quality.

First off, what even is Quality?

All things emerge, change, and die. I think Quality is the experience of the process. The idea of Good Quality essentially boils down to performing the process with grace, and leaving the place better than we found it.

Further, the process of emergence and change—i.e. living—is also the process of dying. It follows that to think clearly about the Quality of the former one must think clearly about the Quality of the latter. The saddest way it can unfold is a slow painful degradation without healing succour meaning or hope. The proverbial death by a thousand cuts. I hope you never witness such a passing, even from afar.

Ok, that got dark fast, and if we’re not careful, we will produce a 300 page Zen dialogue on Motorcycle Maintenance. So we will distract ourselves with the much smaller, lighter—and I’d argue, even pleasant—task of contemplating Quality of software products.

None of what follows is novel, but I feel the message and its surrounding context bears repeating, because if it is not obvious already, software fails us all the time. Far too often with terrible consequences.

Read more →

Technical Debt is really Software Debt. And it’s a AAA-rated CDO.

I’ve long struggled with the Technical Debt metaphor. It was immediately useful when I first heard it. I still think it is useful, albeit as a starting point. The more I worked with software, the more infuriatingly incomplete it started to feel.

Some years ago I found myself in a rabbit hole, researching the 2008 financial crisis. It reminded me of other insane stories like Knight Capital, and further back, about how Enron imploded (because Enron India’s meltdown was shocking, and destructive. And because a dear friend, in his past life, was on the team at Lehman Bros. that structured financing for Enron India. So come 2008, when Lehman imploded, I got to hear about the hard-chargin' super-leveraged risk-takin' days from someone who was there in the early part of the so-called Dick Fuld era. It was all very fascinating, but I digress…).

Down in the rabbit hole, a slow realization began.

One source of my unease is that I think discussions of Technical Debt don’t sufficiently examine the nature of the Risk of the underlying challenge. The other is that the concept skews and pigeonholes the Responsibility part of the underlying challenge. Here’s what I’m thinking.

Note: In this post, I have software organisations in mind, viz. ones that exist mainly because of the software they make and ship (whether priced or gratis).

Read more →