For CTO: When is the time to pay technical debt?

Developers often complain about technical debt and want to get some time to fix it. Be it a significant refactoring, or a rewrite. Usually, this time is a considerable investment. Your gut feeling tells you that this time is better spent somewhere else. Perhaps you think that these are just small issues that bother your developers, and they are not a real problem. What if one of these is a big one? What if one of these complaints is an indicator of a serious issue that will lead the whole team to a stop in a few months? What if the complexity of the system looks like that: source: pexels So how do you distinguish these critical signals from the noise? First, let’s try to understand why is it so hard to identify critical issues among all technical debt complaints. Why is it hard to recognize significant technical debt among all complaints? Some technical debt needs to be repaid ASAP, and some can wait for years without any problem. From a pure developer’s standpoint, these could be indistinguishable. Working with debt, that can wait, may incur much more pain than the debt that needs to be paid back ASAP. Why is that? Well, the technical debt in a part of the software that changes rarely is generally harmless. Even when it is excruciating. Developers should just bite the bullet and do what needs to be done in these rare scenarios. : too much of this painful experience might kill morale, and lead to mental health issues. Be careful here You don’t want that to happen to anyone on your team! On the other hand, even mild level of technical debt in the part of the codebase that is currently undergoing constant change, and will do so for the next N months, is likely to result in a catastrophe. And developers, often, don’t know what are the long-term priorities, because the communication between business/product and technology/engineering is kind of broken. So for them, all technical debt is made equal. So its severity only depends on the pain level that the person experiences when working with said code. So what can we do about that? Stop talking about technical debt The biggest issue with technical debt is that it became this “big mountain of problems” that everybody in the software company refers to when there is any slowdown in velocity, pain in development, bugs, etc. As with any “big mountain of problems,” you don’t know how to solve it because you don’t even know what the issues are. So next time someone complains about technical debt, ask them to formulate a specific problem in the software that has caused whatever issue you are talking about. It is going to be hard. Especially, for developers. And it has to be hard because identifying a specific problem is hard work. And it is rewarding hard work. BTW, I’m writing the e-book called “Through Lenses of CTO: About Technical Debt” where I’m covering the concept of technical debt, and what practices, processes and methods could help you tackle it effectively. I need your feedback! Please read the first chapter that is available for free right now. So, is it enough to start talking about specific problems instead of “faceless mountain of problems?” No, we need to start tracking these. Start tracking specific problems and their impacts Whenever somebody is trying to complain about problems in the software, it really happens because there is some impact on their work. For example, working with a specific class in the system is very painful, and things that you think should take hours — take days. That is a tangible impact! Now, what will happen if you could record these impacts (e.g., 15x slower development of feature “F” than estimated) with their core reasons (e.g., class “X” too coupled to library “Y”)? You will have a list of issues that you can prioritize. You can start recognizing patterns now. For example, there is a set of features “A,” “B,” and “C,” that are affected by the same problems “Y” and “Z” again and again. Now, you could just say, let’s fix it! But what if these features are not going to change much in the next year? That is where the knowledge of what needs to be worked on now, short-term, and what we are planning to work on next, comes into play. Product meets technology First of all, it is likely to be hard to manage the technical debt on a feature-by-feature basis. So I suggest identifying “feature areas” that correspond to specific areas in the codebase. Hey Oleksii! What is a “product feature area?” It is a significant part of the product that contains a bunch of tightly interconnected features. Good examples: Checkout, Wishlist, Search Offers, Admin Panel, etc. This way, you could track the health of these feature areas. Now, you know the health of a particular area, and you know what the list of issues is. Prioritizing problems should be simple. Pick the sickest feature area, right? Nope. The sickest area might be the area that doesn’t require many changes currently and in the future. The area that is relatively healthy, but requires a lot of changes right now, and for next year, is probably your best bet, instead! Even if it is not the worst place in the code, fixing issues, there will pay huge dividends because there will be fewer problems for all these future features that we are anticipating! Conclusion Alright, let’s recap that: Stop talking about “big mountain of problems” (technical debt), and start asking about specific technical problems. Start tracking impacts of these problems on the product. Define product feature areas. Given information about stability (current and anticipated frequency of change) of these product areas, prioritize and de-prioritize these technical issues. PS: what can be improved with a small “inline” refactoring during feature development, shouldn’t appear on the schedule. Make sure your developers have the freedom to make minor improvements during their feature work. Here we are talking about more substantial problems, that can’t be handled via simple refactoring. Thank you so much for reading! If you liked this article, you’ll make me entirely happy if you could give me some claps on Medium (maximum fifty), and you could share this blog post on social media with your following. I need your help! I’m writing the e-book called “Through Lenses of CTO: About Technical Debt” where I’m covering the concept of technical debt, and what practices could help you tackle it effectively. If you want to go the extra mile, of my e-book, give me feedback, and tell me what is your most important question about technical debt. read the first chapter After reading the first chapter, you’ll learn: What is technical debt, really? What is a small (though critical) difference between technical and finance debt? How thinking of technical debt as financial debt will lead your business to ruin? And how to determine whether a specific problem should be fixed or not? I feel that together we could create an invaluable piece for you and for anybody in tech!