On “Technical Debt” and “Building the Right Thing”

Say “Technical Debt”, and the visceral response is usually a shudder, with the mental image being a combination of “Stuff we f**ked up” and “All those shortcuts we took”
It’s not necessarily wrong, but one that doesn’t quite capture the entire picture. Me, I tend to think of Technical Debt as a continuum, with a lower bound based upon the tension between Building the Right Thing and Building the Thing Right.

Knowing that the lower bound exists is important, as it helps prevent overthink.

Building the Right Thing:    Knowing what you are trying to build is hard. I mean, just think of all the different areas that stuff can get screwed up in

• • Your customers get mixed up between what they want, and what they need.
• • You don’t get the requirements — whatever they are — exactly right from them
• • Your team all interpret them differently — even if only slightly, it’s still not exactly the same
• • The technologies that you use to implement stuff has it’s own issues (bugs. features. whatever), that mean what got build wasn’t exactly what you were planning on building
• • In the meantime, your customer’s requirements are a-changing.

And so forth. It’s an old story, and not even remotely surprising.

The bottom line is that even under the best of circumstances, it is hard to build the right thing. We work around this by being Agile, updating our priors with frequent touch-points, and building iteratively, with each iteration bringing us closer to The Right Thing.

So far, so good, right?

Building the Thing Right:    Now, let’s add Design into the mix. By Design, I mean the entire architecture of whatever is being built— the tooling, components, algorithms, UI/UX, everything.

If your Design was perfect, you’d have built out the perfect architecture for each of your iterations when you were Building The Right Thing. The reality, however, is that, there will be situations where the Design for iteration n is not the same as for iteration n+1. This can range from Simple Stuff (“swap out a radio button for a drop box”) to Whoa Nelly (“Swap out Postgres with Cassandra”), but in either case, it means that your Design has changed.

This change in Design, summed over the lifecycle of the project, is your Minimum Technical Debt.
In reality, your Technical Debt will be larger, because not only is your design not going to be perfect in each iteration, but your implementation is also going to be faulty

The Real World:    The point behind all of this is to remove some of the stigma associated with Technical Debt. As you see, the Minimum Technical Debt is not just unavoidable, it is necessary — you need these iterations to be able to actually build what the customer wants/needs. And that, in the end, is why you’re getting paid …😁