The best explanation, I’ve heard till date, for the Technical Debt is the financial analogy – called ‘The Debt Metaphor’ coined by Ward Cunningham, one of the authors of the Agile Manifesto. Ward used the metaphor ‘Technical Debt’ to justify the code refactoring of a finance software to his boss from the client’s frame of reference. Many people have a different interpretation of the debt metaphor, and most of them confuse it with poor & ugly code written in a rush with full of defects, no design considerations, security gaps, compliance issues etc. Technical debt is less technical and a more fundamental modelling issue. It is that piece of work which continues to accumulate because of the missing alignment between a team’s understanding of the problem and the delivered solution at a given time.
It is well understood & accepted that, under time pressure, a team makes conscious or unconscious trade-offs to deliver fast, but at no point, it should serve as an excuse to write crappy code. A team can borrow, time & effort to push the features out of the door, but with quality code. Because, when it does come time to refactor based on the current understanding, the ability to pay back the debt primarily depends on the clarity of the thoughts and extensibility of code take into consideration while writing it the first time.
It is a common problem with both start-ups & large MNCs. The only difference is, start-ups have no or fewer processes to deal with the ugly code, and by the time they realize the problems they have a difficult choice to make between scaling and refactoring. MNCs, on the other side, can afford these experiments in the form of MVPs and generally have the standard processes in place to guarantee a better quality code on regular intervals. Start-ups also have another common problem – high attrition rate, because of which the code base sometimes becomes a mess, a spaghetti mess which is not only difficult to understand but also results in more & more sloppy code, frustrations and poor practices. At this point, the teams come with fancy ideas like implementing new & happening frameworks, re-architecting, having more micro-services, going server-less or moving everything to Kubernetes. And if this doesn’t suffice, going on a hiring spree for more resources, new architect, a more technical product manager.
Refactoring, as Martin Fowlers explains “ is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour”. It is a costly exercise which no doubt helps, but it can only fix the internals. A system architecture redesign, however, is much more difficult because it is a self-portrait of the organization and its enterprise architecture (Conway’s Law).
Often, Product & Engineering teams find themselves involved in horse-trading over technical debt. Engineering Managers (EM) advocates for prioritizing technical debt over everything else because as per them it is a hindrance to deliver new features. Product Manager (PM) on the other hand fear losing valuable sprint time by prioritizing technical debt. It is a more serious problem if an EM sees the technical debt as just a code quality issue or an architecture or an infrastructure issue, the PM is inexperienced to understand this as a product quality issue and, the management fails to see this as a business problem. This infighting soon mounts to blames games, attritions and more embarrassment to the product & business.
Technical debt is a business problem and spans vertically across the organization. The teams need to share responsibility and work together. Most importantly, the management needs to take cognizance of the organization structure, the silos and culture inhibiting collaboration and the conflicting KPIs for the managers.
The work starts with Product & Engineering to understand together the extent to which the product and business are affected by technical debt. It primarily involves building a shared understanding of the amount of impact, duration or periodicity, the timing, refactoring cost dependencies on other technical debt etc.
The PM with the other peers and stakeholders need to analyze the business value of the component impacted, the past, present & future of the component impacted, possible impact on the other components, cost of delay and the lifecycle stage of the product itself. Once this is complete, the technical debt need be prioritized accordingly and, a clear message needs to be sent to all the stakeholders detailing the impact of not prioritizing technical debt and setting an expectation in terms of feature delays.
To conclude, the technical debt grows with insufficient understanding and modelling of the problem domain, which can not be fixed with technical solutions alone. Remodelling and reorganisation must precede refactoring. In order to address technical debt, we need to improve the way we collaborate and build our understanding of the problem we are trying to solve, be open, clear and transparent in communicating and recognizing these type of issues, remove the divider between the business and the system and build a better culture within the organization.
