<commit_before>---
layout: post
title:  "Episode #6: Paying Back Technical Debt With Help From Metrics"
date:   2022-05-17
permalink: /articles/managing-metrics-episode-6
comments: true
tags: guest-post metrics series-managing-metrics
---

## Previously on Tales From a Journey Around Metrics

We briefly interrupted our tale by taking a look at the [5 categories of engineering metrics]({% post_url 2022-05-10-categories-metrics %}). Prior to that, in [Episode #5]({% post_url 2022-05-03-metrics-ep5 %}) Mojtaba discovered how even bad metrics with a decent process could help us ask good questions. 

## Technical Debt

As software engineers, we are either paying back technical debt or creating it! Setting aside the discussion of where technical debt is advantageous, many teams struggle with paying back technical debt accrued over time.

At my last company, we had a development team that was particularly struggling with a large monolithic application that had been in development for 2 decades. The engineers and engineering management struggled to allot time to tackle it, given the need to continue shipping new features. “Technical Debt” was a recurring topic at many retrospective meetings. 

<div id="blog-photo">
	<img src="https://cdn.zappy.app/f7bc416cc73a530f78bbc69f8214b7f2.png" alt="" width="600" height="250">
</div>

## Why Should We Pay Back Technical Debt?

In presenting the argument that it was time to pay down technical debt, the engineering team focused on how difficult the codebase was to extend with new features, how painful it was to set up and debug, and how fixing one thing caused bugs in unanticipated areas of the code. We said that if engineers were given enough time, we would be able to clean it up, modularize it, break it up, etc.

We found that stating the problem in this manner was not effective. It was focusing on _activity_ (of cleaning up, of modularizing, of breaking up codebase, etc.) instead of focusing on _outcome_. As such, it was hard for the business to see the value of paying back technical debt, while it could more easily draw a line to revenue or at least customer impact from new features.

## Metrics as a Tool To Show Impact of Technical Debt

Since we had started to measure some metrics, we found that we were now able to frame the technical debt problem in terms of its impact on customers and developers. For example:

- **Feature Lead Time:** technical debt created manual steps, extra work, and slowdowns in getting features into production, which resulted in long lead times.
- **Onboarding Lead Time:** it was taking new engineers on the team a long time to get set up and be able to commit their first simple fix to production.
- **Mean Time To Recover:** technical debt made it difficult to debug certain incidents, causing our time to recover to balloon.
- **Velocity:** technical debt sometimes impacted our team’s velocity.<commit_msg>final final<commit_after>---
layout: post
title:  "Episode #6: Paying Back Technical Debt With Help From Metrics"
date:   2022-05-17
permalink: /articles/managing-metrics-episode-6
comments: true
tags: guest-post metrics series-managing-metrics
---

## Previously on Tales From a Journey Around Metrics

We briefly interrupted our tale by taking a look at the [5 categories of engineering metrics]({% post_url 2022-05-10-categories-metrics %}). Prior to that in [Episode #5]({% post_url 2022-05-03-metrics-ep5 %}), Mojtaba discovered how even bad metrics - with a decent process - could help engineering teams ask good questions. 

## Technical Debt

As software engineers, we are either paying back technical debt or creating it! Setting aside the discussion of where technical debt is advantageous, many teams struggle with paying back technical debt accrued over time.

At my last company, we had a development team that was particularly struggling with a large monolithic application that had been in development for 2 decades. The engineers and engineering management struggled to allot time to tackle it, given the need to continue shipping new features. “Technical Debt” was a recurring topic at many retrospective meetings. 

<div id="blog-photo">
	<img src="https://cdn.zappy.app/f7bc416cc73a530f78bbc69f8214b7f2.png" alt="" width="600" height="250">
</div>

## Why Should We Pay Back Technical Debt?

In presenting the argument that it was time to pay down technical debt, the engineering team focused on how difficult the codebase was to extend with new features, how painful it was to set up and debug, and how fixing one thing caused bugs in unanticipated areas of the code. We said that if engineers were given enough time, we would be able to clean it up, modularize it, break it up, etc.

We found that stating the problem in this manner was not effective. It was focusing on _activity_ (of cleaning up, of modularizing, of breaking up codebase, etc.) instead of focusing on _outcome_. As such, it was hard for the business to see the value of paying back technical debt, while it could more easily draw a line to revenue or at least customer impact from new features.

## Metrics as a Tool To Show Impact of Technical Debt

Since we had started to measure some metrics, we found that we were now able to frame the technical debt problem in terms of its impact on customers and developers. For example:

- **Feature Lead Time:** technical debt created manual steps, extra work, and slowdowns in getting features into production, which resulted in long lead times.
- **Onboarding Lead Time:** it was taking new engineers on the team a long time to get set up and be able to commit their first simple fix to production.
- **Mean Time To Recover:** technical debt made it difficult to debug certain incidents, causing our time to recover to balloon.
- **Velocity:** technical debt sometimes impacted our team’s velocity.
{'fraction_non_alphanumeric': 0.05607796204479398, 'fraction_numerical': 0.01880663361258335, 'mean_word_length': 4.545023696682464, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5914909', 'n_tokens_mistral': 1517, 'n_tokens_neox': 1400, 'n_words': 887}