This is part of a series called Eight Questions to Ask About Your Tech Debt

• Introduction
• #1: Visibility, #2: Misalignment, #3: Size, #4: Difficulty, #5: Volatility, #6: Resistance, #7: Regressions, #8: Uncertainty
• Using the Eight Questions

The main thing to keep in mind is this diagram (described in the introduction):​

In the last section, we considered two tech debt backlog codebase problems (with codenames in bold):

1. React Func: A React website that has 20% of its pages still using class components instead of functional components
2. Mobile Port: A non-responsive website that needs to work on mobile devices

I scored each both problems on each question and plugged it into this sample spreadsheet from the book.

​https://docs.google.com/spreadsheets/d/1eAaGpiBQYJrQTiVPp8mdSvll-g75LT1UzKmbbufqWxA/edit?usp=sharing​

When I plug the numbers in, I get a net force of 0 for React Func and 0.27 for Mobile Port. But, let’s dig a little deeper. Here’s a radar chart showing both problems and their scores.

In this chart, the Pay Force is seen by going clockwise from Visibility to Resistance. The Stay Force is clockwise from Size to Regression.

The general idea is:

1. If the Pay Force is overwhelming, consider projects to pay it off
2. If the Stay Force is overwhelming, don’t pay without good reason
3. To make progress, target work towards increasing pay forces and decreasing stay forces.

For example:

The React Func project will not be easy to explain to our non-engineering colleagues, and customers won’t care about it at all (unless we break it). The code that hasn’t been converted is working well and is not changed much. Still, it will become more of a problem over time as new team members might not know how to change it safely.

Here’s what I would suggest you consider:

1. In this hypothetical, we already use React Testing, so work to get more coverage. This mitigates the risk of Regressions.
2. Make sure we have enough observability on a spike of new React related runtime errors in production. Build dashboards and alerts to make sure we know if we introduce a new problem. This also mitigates the risk of Regressions.
3. Add guidance to your engineering documentation that these pages should be ported if they are being changed. The PR should start with increasing test coverage. This will reduce Size over time.
4. Make a dashboard showing a burndown of the number of React Class Components, so we can see it reduce over time. This will increase Visibility a little.
5. Do a pilot to see if there is a way to automate this. If so, Size will go down a lot.

At some point, the net force on this project will be decidedly positive and you can schedule time to finish off the rest.

Next: Planning, Part 2