Tech Debt isn't necessarily bad
We should use some nuance
It's the end of 2022, and I am confident that enough has been written about tech debt. It’s a dead horse that has been beaten to death a thousand times. One would assume that the matter is settled and we will be moving on to talk about more pressing matters, which are: I am not sure, to be honest. We will get back to it in a while (or maybe not, as pressing matters aren’t what this post is about).
When asked the question “How can we reduce tech debt?” it more than often turns into a discussion of priorities. In a lot of those moments, the discussion is valid, but just like a significant chunk of the discussions, we are just bikeshedding. Instead, focus on
What is your definition of tech debt? Do people in this room (or the zoom call) mostly agree with your definition?
Why do you want to reduce tech debt?
Is this thing actually tech debt?
Is debt bad? Can tech debt be compared to traditional debt or mortgages? Do you necessarily have to pay it back? From whom have you borrowed the debt?
If you have been an intermediate experienced software engineer and approached the management or leadership to present your “One True Plan to slash Tech Debt by Half in three financial quarters™” it’s very likely you walked back with a sour taste in your mouth, the taste rivaling spoilt milk. Reading Listening between the lines, you can hear them screaming “Ummm, no, I am trying to tell you NO without sounding rude”. The management is either hostile because they don’t understand it or much more likely to have heard this proposition a millionth time. My money is on the latter.
Just ask Netscape when they tried re-writing... you hear that right. Rewriting Netscape from scratch while Microsoft ate its lunch with Internet Explorer (which resulted in another tragedy for the internet). Big-gigantic-huge changes without any short-term gains are extremely risky. We consistently make similar mistakes and need people to review our proposals and whip us back into shape. I personally prefer presenting my proposals of this nature to people who possess no idea of the product so that they can ask fundamental questions which I might have ignored as it’s quite easy to put your blinders on.
Why do you want to reduce technical debt?
Bear with me cowboy! I know you want to bring home the sheep and celebrate with your buddies. Tell me the reason why you want to reduce technical debt? Is it because it offends your sensibilities that something is tied together by duct tape? Maybe the tape is indeed strong enough to hold that thing together till the sun devours our planet. Maybe it’s an aviation-grade speed tape that can hold jet engines together?
At this moment, I am not raining on your parade. We, humans want a reason for doing something? We humans ask ‘What’s in it for me?’. If you are pitching your tech debt reduction bill to your manager or shark tank, you need to explain ‘why’. You are a salesperson and the management is your client. Tell them the value proposition.
Unless you are selling shitcoins, then ignore everything I just told you. At this point even I don’t know anymore. Crypto has become a wildcard.
Does the customer care? How will it benefit the customer?
You can go and ask the customer - Do you want a button which does this? They might understand what that button does. The customer might provide an enthusiastic response which is a ‘yes’ or at worse make you run around because no one wants to spend time understandin if this customer feature will be useful to them.
Now go and ask the customer if they want to reduce the technical debt? The people in the conference room will be looking at each other trying to understand what it means. The finance people might wonder if this is a new kind of bond to raise funds.
At this point, its upto you to understand if this even benefits the customer. Try to keep asking ‘why’ till you reach the actual question. Think of this conversation
Question: Why do we need to reduce tech debt?
Answer: Our CorpseKeeper module has tight coupling with GothamBeautifier which makes it difficult to maintain DogeCrypt for multiple version and deployment takes over 12 hours?
Question: How does the tight coupling make it difficult to maintain multiple versions?
Answer: It makes the developer life difficult as we have to test every version extensively before moving ahead to release.
Question: How will quicker deployment time help us and the customers?
Answer: If we have to deliver a quick fix then 12 hours is too long and customer is kept waiting.
Question: How long should the deployment take? How often are these quick fixes? How much time would it take to bring down the deployment time? What can break?
Answer: …
The conversation can keep going on until the benefits to the customer is determined.
Will it ever bite you in the future?
Its entirely possible that the hack using bubblegum and duct tape is not really solving any major problem or providing any valuable service? How many customer use that code path? Even the most successful companies make aweful products that fail spectacularly. Maybe the customer uptake will never be high enough to make any difference.
Even worse, the software or the component can suffer a slow agnoizing death. At that time, is reducing tech debt a priority?
Time is limited
Take off your software engineer hat and put on your account manager hat. Would it be better to use the time to add another half broken feature? Maybe! If it increases product sales, then why not? There is no shortage of adequately working ‘Temporary Hack, Fix Later’ codeblocks.
10,000 lines of revenue generating rotting code is better than 10,000,000 lines of elegantly written code which passes all linting requirements, but is not really seeing any action.
Maybe good code doesn’t exist at all. Maybe it does and we should focus first on practial requirements like minimum viable product, requirements clarification, timely releases, adequate bug fixes.
This is not a ‘good code’ slander, but a pushback against ‘good code’ getting more attention than it deserves at the cost of multiple other equally important factors.
