MELP #6: How Google Define, Measure, and Manage Technical Debt

Photo by Possessed Photography on Unsplash

This year, researchers from Google, Ciera Jaspan and Collin Green, published a research paper called "Defining, Measuring, and Managing Technical Debt." They've been doing surveys quarterly for the past five years. They figured out 10 categories of technical debt, four ways to deal with it, and created a model to help manage it.

This newsletter is in five parts:

1. 10 technical debt categories at Google

2. Is technical debt measurable?

3. Four ways to manage technical debts

4. The maturity model for managing technical debts

5. Takeaways

10 technical debt categories at Google

Google invested several years in conducting surveys and eventually narrowed it down to 10 categories of technical debt, ranked from the most to the least frequently reported:

1. Migration is needed or in progress: This may be motivated by the need to scale, due to mandates, to reduce dependencies, or to avoid deprecated technology.

2. Documentation on project and application programming interfaces (APIs): Information on how your project works is hard to find, missing or incomplete, or may include documentation on APIs or inherited code.

3. Testing: Poor test quality or coverage, such as missing tests or poor test data, results in fragility, flaky tests, or lots of rollbacks.

4. Code quality: Product architecture or code within a project was not well designed. It may have been rushed or a prototype/demo.

5. Dead and/or abandoned code: Code/features/projects were replaced or superseded but not removed.

6. Code degradation: The code base has degraded or not kept up with changing standards over time. The code may be in maintenance mode, in need of refactoring or updates.

7. Team lacks necessary expertise: This may be due to staffing gaps and turnover or inherited orphaned code/projects.

8. Dependencies: Dependencies are unstable, rapidly changing, or trigger rollbacks.

9. Migration was poorly executed or abandoned: This may have resulted in maintaining two versions.

10. Release process: The rollout and monitoring of production needs to be updated, migrated, or maintained.

The order of these categories is specific to Google's situation. Depending on your company, you might see a different order.

For example, at my current job, we don't deal with large applications like Google does. Instead, we have a lot of legacy projects and outdated tools. Our main issues are Documentation, Code degradation, Migration is needed or in progress, and Team lacks necessary expertise.

Is technical debt measurable?

Google tried to figure out how much technical debt they had by looking at certain words in the code like "TODOs" or "migration." But this method didn't catch all the issues because it relied on what engineers thought.

An engineer’s judgments about technical debt concern both the present state and the possible state.

They realized that measuring technical debt isn't like measuring something with a ruler; it's more about what the engineers think.

For example, imagine your team is updating a piece of software. If they finish updating it to the latest version, that's the current situation. But when a new, even newer version comes out, the engineers might see it as a problem for the future, like a debt they owe.

Four ways to manage technical debts

Google worked really hard to help engineering teams deal with technical debt, which means:

• Creating a technical debt management framework to help teams establish good practices. The framework includes ways to inventory technical debt, assess the impact of technical debt management practices, define roles for individuals to advance practices, and adopt measurement strategies and tools.

• Creating a technical debt management maturity model and accompanying technical debt maturity assessment that evaluates and characterizes and an organization’s technical debt management process and helps grow its capabilities by guiding it to a relevant set of well-established practices for leads, managers, and individual contributors.

• Organizing classroom instruction and self-guided courses to evangelize best practices and community forums to drive continual engagement and sharing of resources. This work also includes a technical talk series with live (and recorded) sessions from internal and external speakers.

• Tooling that supports the identification and management of technical debt (for example, indicators of poor test coverage, stale documentation, and deprecated dependencies). While these metrics may not be perfect indicators, they can allow teams who already believe they have a problem to track their progress toward fixing it.

These ways are helpful if you have a big team and want to make sure everyone does things the same way. The best part, which I'll discuss next, is the maturity model.

The maturity model for managing technical debts

The paper talks about how teams at Google handle technical debt. They use a maturity model with four levels:

• Reactive approach: have no real processes for managing technical debt (even if they do occasionally make a focused effort to eliminate it, for example, through a “fixit”).

• Proactive approach: deliberately identify and track technical debt and make decisions about its urgency and importance relative to other work.

• Strategic approach: have a proactive approach but go further: designating specific champions to improve planning and decision making around technical debt and to identify and address root causes.

• Structural approach: have a strategic approach and also take steps to optimize technical debt management locally—embedding technical debt considerations into the developer workflow—and standardize how it is handled across a larger organization.

Prioritising technical debt is a constant debate between the development and product teams (and stakeholders). This maturity model illustrates how mature teams in Google handle the situation. First, they see how good they are, and then they fix it this way:

• If they're not so good (Reactive), they start by identifying and tracking technical debts, and deciding which ones to fix first.

• If they're getting better (Proactive), they assign one person in charge of figuring out which problems to fix.

• If they're really good (Strategic), they make sure everyone who writes code thinks about technical debt from the start, even before writing the code.

Takeaways

1. Technical debt depends on who you ask and isn't the same for everyone.

2. There isn't a one-size-fits-all approach to categorizing technical debt because what might be considered a priority or a specific type of technical debt in one organisation might not apply in the same way to another organisation.

3. The technical debt management model helps engineering managers and tech leaders figure out what's going on with their technical debts and gives them advice on how to make things better.