Software products are prone to be engineered with cruft that make it harder to alter or extend them. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt.
cruft : badly designed, unnecessarily complicated, or unwanted code or softwareIn other words, technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
Technical debt can be an asset, if used sparingly & wisely. Most software engineering leader run into a cost and schedule escalation during their product engineering journey. This leads to a tough call to be taken as to what technical task(s) could be left out of the current version of the product to take the product to the market. These task(s) left out are referred as technical debt as they are a form of borrowing for ease of execution by pushing today's task to tomorrow.
One of the primary challenges with technical debt is that it needs to addressed in a timely manner. Like any other financial debt, if not addressed in time it could lead to collapse on the system.
Categorizing technical debt
Each technical debt needs to associated with a risk and appetite of the system to bare that risk. For instance, if an improper hygiene like logging with appropriate log levels is left unaddressed as technical debt it would lead to a challenge in RCA and resolution of bug in production system making it unviable for users to use. But if a scalability of the database is left for later, then it would work fine until the user threshold is reached where the system starts to slow down.
Martin Fowler distinguishes four debt types based on two dichotomous categories: the first category is reckless vs. prudent, the second, deliberate vs. inadvertent.
Technical debt quadrants
Addressing technical debts
In case of financial debts, paying the principal off gradually leads to financial well being and reduction is interest on the debt. Similarly for technical debt, if we spend an extra few days to eliminate cruft from the product, then it will reduce the interest rate on future enhancements to a single day. Its still going to take extra time, but by removing the cruft will make it cheaper for future alternations to the product. Think of this as paying interest vs paying of principal.
However unfortunately, remediation task(s) to remove cruft are often left out of the product roadmaps as they don't bring any visible immediate business value. Engineering leaders need to own up the responsibility of address technical debts proactively with their product counterparts.
Experimental nature
Just like an product feature that is experimental and needs validation, few technical debts too are experimental in nature. Often working with a technology or amalgamation of technologies or unique system needs could result in situation that seems to have academic solution but there is no working validation. In agile software development, a spike is a story that cannot be estimated until a development team runs a time-boxed investigation. Spikes are an invention of Extreme Programming (XP), are a special type of user story that is used to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate. Often small Proof of Concepts (POCs) taken as technical spikes help validating a concept. For instance in a n-tier architecture, how much scaling is needed at data access tier and web application tier is often experimental depending on where does the bulk heavy lifting reside.
Closing Thoughts
Technical debts are useful to address the execution issues like skill gap, resource deficiency, bad code inheritance, quick go-to-market due to competitive pressures in short term. Remember, technology is an enabler and the real value is in users benefitting from finished product (even if its with cruft!). But repaying the debt immediately after product shipment is eminent to make the system healthy and not a death trap. If used wisely & sparingly technical debt could become an asset and if used recklessly they are your worst liabilities.
Comments