When considering the role of debt in managing a business, one often focuses on the financial implications – such as interest rates, principal amounts, payment schedules, and associated fees. However, debt extends beyond mere monetary costs. In fact, the majority of debts lack neat numerical labels.
When your auto mechanic warns, “If you don’t address this now, you’ll pay for it later,” that’s a form of debt, albeit its cost may not be immediately apparent. For instance, you can utilize this debt strategically to unlock opportunities – postponing less urgent repairs might enable you to afford a road trip with friends. Conversely, taking on excessive or inappropriate debt – by neglecting all repairs, for instance – could lead to a breakdown during the trip, incurring significant costs. In situations where risks aren’t always obvious, a reliable tradesman who comprehends your requirements and can elucidate necessary improvements proves invaluable.
This principle holds even truer in the realm of software development. Technical debt arises from prioritizing short-term gains over long-term objectives. While it can serve as a valuable tool, it can just as swiftly transform into a hindrance that impedes progress. Accumulating excessive technical debt, doing so at inopportune moments, or acquiring the wrong type can leave a project in a precarious state. The three crucial factors – the nature of the debt, its overall quantity, and the timing of its acquisition – are pivotal in determining when it’s prudent to assume additional technical debt.
Now, let’s swiftly delve into various facets of technical debt and discern when, or if, it’s advantageous to leverage them within Increments Inc.’s operations.
Just like any other form of debt, technical debt necessitates payments towards both the principal and interest. When developers invest time in redesigning and reconstructing code to apply learned lessons—what we refer to as refactoring—that constitutes a payment towards the principal. Conversely, when developers waste time grappling with outdated code that requires updates, that’s a payment towards the interest. If technical debt accumulates excessively, interest payments can overwhelm all other work, bringing the project to a standstill.
To illustrate, I once inherited a project where there were frequent requests to add more data to a specific screen. Based on their past experiences with previous developers, the client anticipated a one-week turnaround for each request. However, after refactoring the code within that same timeframe, subsequent requests took less than five minutes. By addressing the technical debt, we paid off the principal once and for all. Instead of each request costing the client a week every time, it only cost them a week one last time. Unfortunately, this example isn’t an isolated incident.
Determining whether your project is burdened by technical debt requires keen observation. While the following list isn’t exhaustive, here are some telltale signs indicating the presence of accumulated technical debt within an Increments Inc. project:
Among the various ways to conceptualize technical debt, one of the most valuable and widely recognized frameworks is Martin Fowler’s Technical Debt Quadrant. According to Fowler, all technical debt can be categorized into four quadrants:
Inevitably, inadvertent technical debt occurs, but practices such as code reviews, QA testing, and continuous training mitigate the extent to which it catches a team off guard.
Reckless and Deliberate technical debt steers the project toward failure, often because unreasonable demands aren’t met with adequate resistance.
Conversely, Prudent and Deliberate technical debt can serve as a useful strategy for meeting tight deadlines, provided there’s a plan in place to repay the debt later on.
Now that we understand the types of debt, let’s explore when it makes sense to consider taking on technical debt :
When prioritizing the first mover advantage: In certain situations, being the first to market may outweigh the importance of being the absolute best. In such cases, expediting the journey to market—albeit with a plan to rectify shortcomings later—may be the more prudent course of action.
When quality is of minimal concern: A proof of concept is typically intended for temporary use and can be discarded once it fulfills its purpose. Consequently, any technical debt incurred during this phase dissipates along with the prototype.
When there’s a high risk of project abandonment: Not every idea translates into success. It’s often preferable to launch a Minimum Viable Product (MVP), gather market data, and then allocate resources to areas demonstrating the most promise.
When immediate delivery is imperative: In instances where a critical bug is affecting live systems, implementing a partial fix to ameliorate the situation may be preferable to taking no action at all.
However, in each of the above scenarios, it’s crucial to evaluate the technical debt being considered against the technical debt already accrued. Timing is just one aspect to weigh; you must also factor in the type and overall quantity of debt already accumulated.
Technical debt is an inherent aspect of software development, but effectively managing it necessitates foresight and strategic planning. Here are several pointers to help you prepare for technical debt within your Increments Inc. project: