The 25 Percent Rule for Tackling Technical Debt

Let’s talk about technical debt. Let’s talk about practical usable approaches for actually paying it down on a daily, weekly, monthly, and yearly basis. Let’s talk about what debt needs to be fixed now versus what can wait for better planning.

Shopify logo
Shopify
•
John DeWyze
•9 min read•intermediate•
--
•View Original

Overview

The article discusses the concept of technical debt and introduces the 25 Percent Rule as a framework for managing it effectively. It categorizes technical debt into four types—Yearly, Monthly, Weekly, and Daily—and provides actionable insights on how to allocate time for each type to foster a culture of continuous improvement within engineering teams.

What You'll Learn

1

How to categorize technical debt into Yearly, Monthly, Weekly, and Daily types

2

Why it's important to allocate 25 percent of time to address technical debt

3

When to prioritize refactoring code to improve ergonomics and maintainability

4

How to empower teams to address Weekly Debt through project boards

Key Questions Answered

What are the different types of technical debt and how should they be managed?
The article identifies four types of technical debt: Yearly, Monthly, Weekly, and Daily. Each type has distinct characteristics and requires different approaches for management, emphasizing the importance of allocating specific time percentages to address them effectively.
How can teams effectively allocate time to manage technical debt?
The 25 Percent Rule suggests allocating 10 percent of time for Daily Debt, another 10 percent for Weekly Debt, and 5 percent for Monthly and Yearly Debt. This structured approach helps teams balance immediate coding tasks with long-term improvements.
Why do teams often neglect to fix technical debt?
Teams may neglect technical debt due to fears of wasting time or because refactoring is perceived as boring. The article highlights the pressure to ship features quickly, which can overshadow the importance of maintaining code quality.
What is the significance of the 25 Percent Rule in addressing technical debt?
The 25 Percent Rule emphasizes a balanced approach to managing technical debt by ensuring that teams allocate sufficient time to address various types of debt. This fosters a culture of continuous improvement and code quality within engineering teams.

Key Statistics & Figures

Time allocation for Daily Debt
10 percent
four hours a week
Time allocation for Weekly Debt
10 percent
This time can be used by teams to work on project board items that address Weekly Debt.
Time allocation for Monthly and Yearly Debt
5 percent
This time is intended for planning discussions regarding Monthly and Yearly Debt.

Key Actionable Insights

1
Encourage engineers to spend up to 10 percent of their time on Daily Debt to improve code quality.
By allowing engineers to dedicate time to refactoring during their regular work, teams can enhance code ergonomics and reduce future maintenance burdens.
2
Implement a project board to track Weekly Debt items that can be addressed in sprints.
This approach allows teams to manage technical debt without disrupting their workflow, ensuring that improvements are made systematically.
3
Allocate time for Monthly and Yearly Debt discussions during planning meetings.
These discussions help prioritize which larger refactoring projects need to be tackled, ensuring that technical debt is addressed in a timely manner.
4
Foster a culture that celebrates refactoring and code improvements.
Recognizing the efforts to improve code quality can motivate engineers to address technical debt more proactively.

Common Pitfalls

1
Teams may avoid addressing technical debt due to the fear of wasting time.
This often stems from a culture that prioritizes shipping features over code quality, leading to a backlog of technical debt that can hinder future development.
2
Refactoring is often seen as boring and unrecognized work.
Without proper recognition, engineers may feel discouraged from spending time on improvements, leading to a culture that neglects code quality.