One of the problems which would arise quickly in growing product is a phenomenon called technical debt. It’s one of the most misunderstood phrases in the IT industry. Some people think of it as an incarnation of the darkest evil and try to avoid it at all cost. And often, the scariest statement for any product CEO can be heard somewhere around: “We need to rewrite it!”. You probably have gooseflesh even reading this.
So what is technical debt?
We should treat technical debt as a tool, the same way we treat a bank loan or a credit card - as a financial instrument. They can be used for achieving our goals, or they can be harmful in irresponsible hands.
Mario Andretti, an F1 driver, said once:
If everything seems under control, you're just not going fast enough.
And there is something in that quote. In the first phase of the product life cycle, consciously incurred technical debt is fuel for propelling that immature vehicle. It wouldn’t be wise to invest in convenient car seats when we don’t know where we are heading to and when we will refuel. Although moving out successfully from the MVP phase with no technical debt at all is technically possible, it’s hardly occurred in reality. It’s usually a sign that you have driven too slow.
It’s all about context
It is worth mentioning that technical debt, in its original definition, requires consciousness from a debtor. So in the moment of decision, in spite of awareness of superior solutions, we choose the imperfect ones due to some constraints (like budget), which we value more at the moment. And all these minor imperfections add up to the perfect solution for the given context. But having only a hammer in hand and seeing nails everywhere isn’t incurring debt. It’s just incompetence.
Source: monkeyuser.com
Let’s assume that you had a healthy relationship with excellence before, though. Your product got traction, you have a few happy customers and investors believed in your vision. Some kind of funding was established, so the money was no longer a problem. So does it mean that we should repay all the debt from the previous phase? Well. It’s one of the options. Let me answer that with a question. Should you pay off your mortgage if you just received a fat bonus or inherited some money? It depends. How big are the interest rates now? What does your liquidity look like? Do you have alternative ways of investing cash with interest higher than the mortgage?
How to manage technical debt?
When we treat debt as a tool, we can approach it pragmatically and healthily. Thus, we shouldn’t speak about paying it off but rather technical debt management. This means adjusting company leverage. If the interests eat all our efforts, we should think about deleveraging. If the dev team constantly struggles with delivering new features, then a surgical refactor in a contention point will probably allow them to breathe. How to decide where we should put the pickaxe? In the beginning, it’s good to define where we should not. Generally, code smells aren’t that a serious problem if they are relatively separated in the way, they don’t interfere with the main flow of development. If something works and it’s hardly changed (or even not changed), we should focus on other most vital places. On the other hand, if we see or expect a heavy flow of future improvements in some product sectors, it’s a perfect place for spending time there and reducing the toll. This kind of triage is called optimisation for changes vectors. Refactoring only for the sake of refactoring is usually burning money.
Balancing perfection
It may sound straightforward, but actually, the case is more complicated. On the logical plane, it’s a perfectly justified approach. But the software is created by humans, not robots. Thus individual perspectives, emotions and goals come into play. Developers usually have a natural inclination to be perceived as competent specialists in their field. This is something that is honoured in the programming society. If you act like that, you can be proud of yourself and feel part of the tribe. So it often feels just wrong to write something imperfect, it feels like breaking the creed. This syndrome is especially apparent in young, ambitious folks. And I believe that natural enthusiasm should be used for the good. That’s why we need more seasoned leaders who can help channel those aspirations and forge win-win situations for the product and the team. At the end of the day, no company can exist without great people.
Source: dilbert.com
To summarise. Working with technical debt isn’t a fire and forget activity. It’s rather constantly keeping things balanced and finding sweat spots. Technical debt management requires excellent empathy, pragmatism and communication. Besides this problem, in the post MVP phase, you may encounter other problems that I described in this article.
