Let’s talk about (Technical) Debt, Baby…
Till debt do us part
Let’s start by being honest: Technical Debt management is a curse. For all of us. Developers, software makers, salespeople, marketers.
A curse.
But it’s all going to be fine. We could talk about what should be classified Technical Debt, but that’s a future blog. Today, I want to explain what Technical Debt really is.
Semantics, semantics, who wants my semantics?
For those of you who don’t know what Technical Debt is, I’ll start by explaining the basic meaning, using the words of the man who coined the term.
[If you already know all about it, collect a gold star and skip to the next section.]
Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
— Ward Cunningham
Cunningham’s brilliant idea is that, when you write software, you make a lot of small decisions that compromise your “perfect” solution. You know, the one ideal solution that would take a nearly infinite amount of time to implement, if it is possible at all.
That’s what we’re talking about here: the sum of all those little decisions is the Technical Debt you’re creating. You’re betting that releasing the software earlier will ultimately get you more revenue. Sweet deal. Better ROI. Profits. Dinero. Unicorns.
Like all debt, however, the technical type generates interest if you don’t pay it off right away. Booo! Hiss!
Technical Debt management is all about finding the right balance between accruing that debt and paying it. You want to manage it carefully… very carefully. It’s confusing even thinking about it, right? So, let’s clear it up.
Metaphors are bad! Aren’t they?
A lot of people use the metaphor of home ownership to describe Technical Debt.
It goes a little like this:
Think of the software as a house your Product Manager, or some other human, wants to turn into a rental property. They want to make money as soon as possible, which means getting the house ready as quickly as possible. Saving for 30 years creating perfect software in order to have the perfect, money-making home is not going to work for this person. They are fine with employing a team of builders to make some necessary (hopeful minor) renovations, but only enough to get the place on the market.
It’s not like the Product Manager is looking to spend a lot of money on the house in the future. They want to quickly find paying tenants (users). After that, would probably be happy not to hear anything more about it… except the sweet rustling of dollar bills each month.
So one day, our imaginary friend and team visit the Magic Bank of Compromise and take on a significant loan (Technical Debt). The banker is certainly happy. They’ve got them on a high-interest rate loan, the “You’re Gonna Debug Cron Jobs for the Rest of Your Life” package. The team makes a lot of pained faces, but the Product Manager thinks it’ll be fine. They make those faces all the time, anyway.
“Squeeze the renovation by four weeks, and we’re all gonna be stinking rich,” says our Software Maker in chief. Everybody agrees. If they can rent it a week, a month, two months earlier, the sooner they’ll be farting through silk!
The team works hard. They squeeze and they squeeze. This ain’t going to take 30 years! They get the job done and the owner starts finding paying tenants.
But the debt is still there. And there’ll be no zillionaires until they pay everything back.
In my experience, happy endings to this scenario are rare.
Our metaphor has been cracking a bit as we go along, but here, it completely shatters.
Meta-crack
For one thing, with software, you rarely ‘rent’ it once and then leave it alone. It needs maintenance. It requires upgrading. You have to give your users what they want.
And then, there’s always more than one metaphorical house.
You’ve got your Customer Relationship Management (CRM). You’ve got your Enterprise Resource Planning (ERP). You’ve got your customer’s user interface (UI). You’ve got your so-ons and so-forths. Even if you farm out all the renovations to contractors, you still have to do the integration between all of them by yourself. That’s a lot of crappy houses to put on top of the other to take on debt for…
In summary: looks like you have a steady stream of renovations for a growing number of houses. And, of course, your tenants don’t want to leave the house while you fix it up for them.
Okay, time to put the metaphor aside.
Now in software, the Product Owner, Manager, or whoever, is the only one who decides what needs to be worked on, fixed, or ignored. In such a situation, the software team becomes like external contractors, paid to be focused solely on the owner’s chosen fixes (if you’re lucky enough to have an owner who wants to fix things).
Sadly, it is very rare to find a software ‘owner’ willing to spend any more time maintaining software than is absolutely necessary. Even worse, it is even rarer to find one willing to actually invest in repairing obscure, technical parts that have no consequence now, but will in an hypothetical future.
And here the metaphor breaks again: it might be easy for a homeowner to understand that fixing a cracked pipe or a leaking roof is worth doing, but that is simply not the case when fixing deployment pipelines of multi-component software, writing endless tests, ensuring they are continuously run, or refactoring the 15 hour running billing job.
But wait!
You can have a happy ending. That’s where I think we can fix the metaphor.
Unicorns, at last!
Since we’ve let it back in, let’s rework the metaphor a bit.
Let’s say our software is not a house. It’s a co-owned, condo-style building.
Some of our software makers live in it. They’re not only the makers of the building, they own part of it. They maintain it. They fix the plumbing. They install a solar-panel rooftop, take care of their cats, and so on.
Meanwhile, our greedy Product Owners are still renting the place to the highest bidder. Sometime they rent it to other software makers, but usually to simple users. Scary, I know, but it’s okay. They’re the owners. As long as they’re happy…
Now, when you look at it like that, Technical Debt management is not financial debt management anymore. It has morphed into asset management.
The software team is not an external contractor that tries to make do with the space and time provided by the owner. They are co-owners and take on the responsibility of ensuring that the building stays in the best shape it can be.
Now, if you know a bit about building management, you know it’s never, ever free.
Fire. Bath overflows. Water damage. Solar rooftops. Crazy serial-killer cats living with submissive dogs. Mass hysteria! For all of these reasons and more, every building owner concerned with maintaining healthy assets has to manage some sort of ‘fund’.
Managing a condo fund is pretty simple: every month, owners pay a condo fee negotiated annually between the owners and the condo management. Together, they count up the accumulated condo fees and the building expenses incurred during the year. The bottom line reveals if they can expect a good financial net for the coming year, or that the condo fees need to be raised. Simple as that.
It is my strong belief that treating software in a similar way makes everybody’s life easier.
Software makers, after all, have a direct stake in the software they build: they maintain it. You might say they ‘live’ in it. They make and maintain the rooftop (the UI), the plumbing (the back end), and everything in between.
Product Owners will also want the best for their condos, which should include wanting the best for the building. Cause without the building… there’s no condo!
Managing Technical Debt: How can it be done?
What is the software equivalent of a condo fee then, you ask? (Yes, you asked. Don’t lie to yourself.).
We could call it the Technical Debt budget. But maybe it a more accurate name. Call it the software asset management fee.
No matter what we call it, the principle is: every iteration/month, a specific ‘time allotment’ is freezed-out of our software making.
Yup. We remove time from our iteration sprint. Time is money, remember? So, there you go. That’s our condo fee.
This budget is then used by the software makers to address the Technical Debt or “software asset lifecycle management”… if you want to get pedantic!
Whether it is fixing something broken, predicting what will soon break, or someone needing to learn a new skill: we pay to make sure the plumbing is working properly, the elevator goes up and down, the solar panels generate power, and the serial-killer cat and submissive dog are both medicated.
Not only does it ensure the building has a future, it provides software makers and the owners with a healthy practice for the ever-faster pace of delivering the next apartment level.
Levels of happiness rise. Technical Debt goes away. Assets grow. Unicorns prance. Zillionaires dance.
Yes… you’re welcome. :P
