Technical debt is a term coined by Ward Cunningham to describe the cumulative consequences of corners being cut throughout a technology product’s design and development cycle. In other words, it’s the sum-total of longer term consequences of poor decisions / design choices – typically taken with the purpose of achieving rapid growth in product development and faster time to market.
Valuing Technical Debt
How would you know how much cumulative technical debt you have? Financial debt, for example is expressed as a % of GDP, as a % of asset value (LTV), as a fraction of EBITDA (Debt/EBITDA ratio). But for technical debt, there is no quantitative measurement. Rather, it’s reflected in the increasing development cost of product with time, reduced customer responsiveness, slower new feature release, increasing internal conflicts between technical and sales teams, an increasing number of issues/bugs with every release, and lower developer/product team morale.
Generally it’s not possible to escape generating technical debt as part of a development cycle; but also, it’s not as evil as it sounds. Much like taking mortgage debt on a house, technical debt also has its merits. Most home buyers end up taking a mortgage since the price of the home is outside of what they can pay for in cash. Similarly, technical debt allows you to deviate from perfection in order to gain product development benefits.
But it’s crucial to manage and keep control of this debt with skill, foresight and discipline as just like a mortgage, if one misses interest payments, the debt burden multiplies exponentially with penalties over time crippling the tech team.
Acquiring Technical Debt
Often a function of the firm’s life cycle
• Large enterprises tend to have more legacy infrastructure, resulting in greater and riskier technical debt. However, I have experienced this being managed very well at a large and complex FinTech product firm.
Culture and hierarchy of the firm
• How is accountability and responsibility determined within a firm? For example, if technology architects / product managers are moved around frequently it’s hard to track the implications of one’s past decisions. And if such is the culture, short term thinking will drive the decision making process, leading to an accumulation of technical debt.
• Next, the way different teams share responsibilities, and how they work together also define the technical debt. Take a look at the amusing illustration below of how the organizational structure at several well-known tech firms defines the product they deliver.
Is technology an actor or a director?
• There are many decisions in the development of tech which result in different alignment of interests. Is the tech outsourced or insourced? Is the tech building a product or supporting a product? Is scalability a longer term concern?
Competing priorities
• Many times, there are conflicts between sales and engineering teams on competing client priorities vs. building the product in a well-designed manner, which usually takes longer. The resulting is time vs. quality debates, which is healthy for the firm
Product life cycle
• When a firm is arriving at a product market fit, or when it’s in R&D mode, it incurs technical debt in favor of time to market. But it’s important to note those decisions and not take too large a debt, which would affect the agility of technology assets. If a product is a cash cow, the focus is on maintenance vs. optimization, and if it’s either a problem child or a dog, paying back of technical debt is forgotten, creating a maintenance nightmare.
How to Optimize Technical Debt?
At the end of the day, it’s the skill, determination and discipline of the product architect/owner to manage the technical debt over time. Her sense of timing and ability to make firm decisions on incurrence/avoidance of this debt are critical, engaging all the stakeholders involved while navigating the product development forward.
Optimization Strategies:
1. Prevention: Establish best practices in coding and documentation, peer reviews, automated testing and abstraction. Automate processes to perform regression tests / source code analysis. Leverage off the shelf tools like Jenkins and SonarQube.
2. Identification: Ensure ownership and visibility of technical debt at all times. (a) Create processes to explicitly tag technical debt issues. There are plenty of tools available to track this data. At DiligenceVault, we use Pivotal Tracker, for example, which not only helps with maintaining momentum, but also helps to track the amount of time spent on features, bugs and chores. (chores being attributed to non-feature related work). (b) Have explicit ownership for various components of technology architecture components, including development, dev ops and infrastructure.
3. Measurement and trade-offs: Evaluate the size and impact of the debt at the time of incurrence. Evaluate the associated tradeoff and risks around architecture decisions with team members and product owners. This process is analogous to how a home buyers would evaluate taking a 3/1 arm with no caps, in a rising rate environment.
4. Monitoring triggers: Use tracking tools to collect metrics –i.e. defect rate, time spent to refactor, and feature development over time, all of which will drive prioritization decisions.
5. Repayment schedule: Maintain a quarterly schedule and allocate resources to debt items in the backlog from time to time.
Technical debt is often kept under the radar as opposed to frameworks and coding efficiency. As someone who has worked in a successful product company, as well as in multiple startups, it’s fascinating to examine the concept of technical debt, the skills that go along with management of technical debt, and how the process can be an enabler of the organization’s success.
