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
- Planning with the Eight Questions, Part 1
The main thing to keep in mind is this diagram (described in the introduction):
As a recap, in the last two e-mails, we considered two tech debt backlog codebase problems (with codenames in bold):
- React Func: A React website that has 20% of its pages still using class components instead of functional components
- 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.
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:
- If the Pay Force is overwhelming, consider projects to pay it off
- If the Stay Force is overwhelming, don’t pay without good reason
- To make progress, target work towards increasing pay forces and decreasing stay forces.
See the previous e-mail for a discussion of React Func.
The Mobile Port project will (in contrast) be easy to explain to our non-engineering colleagues. Customers on mobile will value it. It is an important part of our business strategy, so we have to do it. The question is whether to pay the debt with major changes (close to a rewrite), or whether to make minimal change to get things working.
Here’s what I would suggest you consider if you want to make paying work:
- There is probably more than one way to do this, so doing a proof of concept of various choices will give us a more accurate estimate (hopefully reducing Size) and definitely reducing Difficulty and Uncertainty.
- Like in the previous project, automated testing and observability will reduce the risk of Regressions.
- Projects like this might be possible to do a little at a time and deployed alongside the current version. If you can break down the site into sections that can be migrated and deployed early, you will also reduce Difficulty and Uncertainty.
- Another option is a total rewrite to a site that supports both desktop and mobile sizes. I recently did this on my project that was in MVP because it was still relatively small and not many users (Size and Regressions were very small comparatively). If you do this, then keeping the current site going is essential. Chapter 30 of the book details a time I needed to do this — you can read an early version in Section 7 of this article on the Pragmatic Engineer newsletter. It’s probably a good idea to make the current site work as best as you can on mobile during this time and to make minimal versions of the rewrite available. We did this on my MVP with mobile versions with a subset of the functionality, because something was better than nothing for our user cohort.
The main difference between Mobile Port and React Func, is that Mobile Port is highly visible and required by our business, while React Func’s benefits are mostly internal. Another difference is that Mobile Port is much bigger and riskier. They end up with similar net forces, but if you look at the details, they are different. You would likely allocate much more time to Mobile Port if you had both of these issues.