TechDebt aka another way corporates can exploit you
You might not agree with me but it’s time to get away from this giant monster we have created — Scrum.
I’ll not talk about what is agile and how scrum implements it, if you do want to know, I can write another article about it. I’m here to talk about one of the worst terminologies I ever came across in scrum practice — TechDebt.
What the heck is TechDebt?
In his article, Raphael Moutard, clearly points out the various definitions people have:
And none of the above definitions are wrong.
TechDebt is “technically” the implied cost of additional rework, because you are choosing to take the easier path and coming up with a solution instead of taking a better one that could take longer.
Things you are made to do in the name of “TechDebt”
The problem is that the term is often taken for granted and even misused. Something is just tagged as TechDebt, even when it is not something that is consciously decided by the developers to make their work easier. In fact, they are the ones who face the brunt of it in the long run, while making it seem like they are just correcting their own mistakes.
Do you feel the gravity of the situation? We are asked to pick something up as TechDebt very easily without proper description and sometimes it means re-writing the whole piece of code.
We had an application that performed batch processing of some cross-referencing data and update them. Initially, there were no updates so our workflows using these cross-referencing data used to pass. Later, the updates increased due to which our workflows started failing quiet often. A decision was taken to update the cross-referencing data through some real-time application. I remember my manger telling me when I asked him this question — “Why did we not do this in the first place? This seems pretty straightforward to me.” He replied, “It’s only now that we got to know that there can be these many changes in the data. Earlier during our product discovery phase, this detail wasn’t provided to us.” We were told to pick it up as a TechDebt. But we didn’t just have to make change, we rewrote the whole code. Our code was different, the framework was different. In short, no part of the old code was reused.
We did not choose to take a shortcut or delay necessary upgrades, we worked based on the information provided to us. But we had to spend extra time and resources to fix it.
TechDebt comes with a COST
When you go to the bank to get a loan, you get a proper contract stating the interest you’ll be paying and you prepare your mind accordingly. But with TechDebt, you can’t even measure the interest. No one tells you about it, not even in fine print. This interest can be in the form of frequent errors, increased development time, and reduced productivity.
Now you could call it a necessary evil, as it is needed in MVP development or meet short-term deadlines or for temporary workarounds. It can also be a part of the learning process to try different approaches and unconventional solutions. But you always know, that you cannot neglect them and you eventually have to put in the extra work required to perfect your code. So why postpone it?
We have this doha in hindi,
Kaal kare so aaj kar, aaj kare so ab…
It means that, instead of putting something off for tomorrow, get done with it today. You might have to put in some extra hours and it might seem irritating but when you realize how it saves you from challenges and costs in the future, your future self will thank you.
In his article, Raphael mentioned that TechDebt is a tool, it’s neither good nor bad, it depends on how you use it. I beg to differ. Suppose there’s a house built using woods and now, you feel like replacing woods with bricks. The house remains the same, but the material is changed. It’s a new house altogether. Everything's changed.
While designing, utmost importance should be given to choosing the right framework and the right language. The final product should be such that it remains useful for at least 10 years. So make sure that you keep that in mind. Completely eliminate the term from your dictionary as it will improve the quality of your code and even though things might seem difficult now, it will help you in the long run. As an additional perk, no one will be able to make you rewrite something in the name of TechDebt (because the term will cease to exist).
