Last updated on November 26th, 2022
In the agile enterprise technical debt is a reality…something that you don’t want but have to face anyway. Time and market pressures inevitably lead to technical debt in the software universe. Releasing a product sooner is immensely beneficial for a business and falling behind in a rapidly changing technology environment can spell disaster.
In the face of these challenges, enterprises often take on technical debt. Just like how accumulating some financial debt to purchase a house is healthy and accumulating debt like credit card debt, problematic, the enterprise also has to take on some amount of technical debt to remain relevant in today’s dynamic business environment. But too much of it can become a crushing burden.
But do the principles of technical debt apply to the software development context alone? I feel the concept of technical debt applies aptly to the functions of running the enterprise as well.
Debt, in the simplest sense of the term, is a form of borrowing today with the intent of repayment in the future. It makes sense to borrow if it leads to a better tomorrow. In the enterprise context, debt is good if it provides a better return than the cost of debt. It, therefore, makes sense to be completely aware of why you are incurring the debt, how much debt you have accumulated and the payback plan.
Clearly, you have to measure and manage any debt in a planned manner to make sure that the debt does not impact profit, restrict flexibility and doesn’t impact the future of the enterprise.
Technical debt and business context
In the business context, we often make decisions that have a positive short-term impact. The C-suite, for example, might feel that living with an existing problem makes sense for the present and solving that problem later might be more beneficial. So, you continue on the existing path, taking a patchwork approach. You do what is needed for immediate benefit, sweep the problem under the carpet and leave the cleaning up for later. It might work for a period of time. The problem is if there is no clear plan to mitigate the challenge. The mess under the carpet keeps building up and it becomes difficult to identify which problem to solve first.
Taming the debt
In the enterprise environment, chances are you will have accumulated some kind of debt. It could be in the form of processes that are less than optimal, culture changes that need to be implemented but are put off for later, technological changes that need to be in place but owing to time and resource constraints are not managed proactively…the laundry list is long. So, how do we solve the problem?
1. Define the problem
Identifying key problems is the first step. In technical debt, we have to determine the pattern of debt-resolution seniority to determine where you must begin. We usually begin with mission-critical systems to evaluate what technical debts they have and then begin to look at the wider ecosystem. We also have to evaluate what technical debt between systems is causing extra expense. Taking a top to bottom assessment is a good place to start to get a comprehensive idea of the debt volume. You then assess how this year would have played out if you had completely cleared up all of our technical debt a year ago. With this information in place, you can design the debt clearance matrix and list the easy/hard to pay the debt on one axis and the benefits on the other.
2. Assess the payment plan
When dealing with technical debt, much like financial debt, we need to evaluate if the debt is small with a low-interest rate or if there is a prepayment penalty. If this is the case, it is best to leave the debt for later as there can be some strategic advantages too – for example, being one version behind can be fine and can give you the advantage of someone else working out the kinks.
Paying back technical debt involves a cost– in the form of replacing old systems and also in the time and resource context. Evaluating if it makes sense to solve the problem immediately or do it over time through gradual improvements is critical.
Solving business problems is no different. You need to assess the business impact of a decision and then take measured and calculated steps to solve the problem, pay back the debt and ensure a positive business impact.
3. Manage future debt
Once the old technical debt has been cleared, software development teams have to preserve the visibility and ensure new debt doesn’t build up. You need to implement practices that help define how you can proactively have a debt repayment plan in place.
Taking a similar approach to managing business decisions ensures that we learn from previous mistakes. It is important not to get blinded by immediate gains that impact future value and growth. Just like how leaving technical debt inside the code leads to more technical debt, putting off business issues for later can become insurmountable and can take more time, energy, effort, and money to resolve.
In software development, mostly in traditional teams, ‘done’ is equated to good enough for QA to start its work. However, bugs creep in early in the release-cycle and continue to build. By the time QA gets to work, they realize that they are saddled with layers and layers of defects.
In agile teams, on the other hand, ‘done’ means that developers will not move to the next level until the current feature is of high-quality and demonstrable and is practically ready to be in the customer’s hand. Modern-day businesses, too, should follow the agile approach to make sure that they can measure and manage the issues at hand and that short-term gains do not leave a long-term impact.
