1

User Pain is an established concept to prioritize bugs in a consistent way that is stable over time by calculating a single score based on a small number of criteria.

While these criteria can vary across organizations, they usually share a number of qualities:

  • Good coverage: These cover the range of concerns expressed by most stakeholders. Type includes business priorities while Likelihood and Priority help classify user impact.
  • No overlap (aka orthogonal): A bug can be rated on one factor without affecting how you would rate the other factors. This allows you to rate each factor in isolation and greatly improves the objectivity of the results.
  • Small number: There are few enough of them that they don’t overload the bug submitter. It is easy to add more factors for various edge cases, but typically this results in a cluttered and confusing bug submission form.

I would like to adopt that concept for prioritizing technical debt and maintenance in a large, old, but actively developed code-base. Meaning maintenance work that is not directly user-facing bugs.

It being a large and old code-base, there are tons of tickets like:

  • [Maintenance] Do not bind against SomeProvider in ChangeOps
  • Make X maintenance script more database friendly
  • Create Docker-based CI job to build some specialized GUI
  • UnitTest noise from DataUpdaterOutputManagerTest
  • Write ADR and Docs about Caching in some specific domain
  • Performance audit
  • Unify react templates
  • Migrate old ruby browser tests
  • ... etc.

What criteria would you suggest for ranking such tasks in order to create something like "Maintenance Pain" or "Developer Pain", so that one can then just pick the ticket with the highest pain score?

2

The user triage ones probably carry over better than you think with a modified scale / criterion.

Taking the metrics proposed in the first link, type goes on a spectrum from 1 (documentation) to 7 (crash) with milestones for usability pain. On the devops side, 1 (documentation) still works pretty well (going back to the ADR example) to daily annoyances (the build takes too long) all the way up to this completely stops my day (having to reboot a CD/CI worker node, for example).

Priority (pain) would also be a similar scale, going from nuisance to blocking further progress. The scale seems like it will work with some wordsmithing on the examples.

Again, likelihood also carries over with only wordsmithing changes if you think of developers as users of the tool or process.

You can probably use the main inputs you have already, but taken from a developer point of view instead of an end user point of view.

The one thing that will have to be reconciled at some point is that developer pain and user pain are not equivalent in the prioritizing of work. The latter is only really addressed in most organizations as a force multiplier on the latter. The customer's needs will always trump ours because, at the end of the day, we are in the business of solving problems for someone else. And where there's muck, there's brass.

1
  • Thank you, you are making a good point. Now that I'm looking more into it, I think it is possible to find equivalency for type and priority (or severity as the second link calls it). But I feel I have to think more about likelihood/prevalence. With feature work often focussing on specific areas of the code, that value might be very situational and thus not stable. But maybe that itself could be a scale? 🤔 /me goes for a walk to think about it. – Michael Große Jul 15 '20 at 17:33
0

What criteria would you suggest for ranking such tasks in order to create something like "Maintenance Pain" or "Developer Pain", so that one can then just pick the ticket with the highest pain score?

I believe you are looking at this from the wrong direction. You basically have N tasks labeled maintenance or technical debt and you want to compare them together to figure out which one is the biggest issue, fix that first, then continue down the list until all things are fixed.

But you are forgetting something.

Technical debt and messy code affect not just the maintenance but your current work and new features. Technical debt means you decide to make a mess now to gain some benefit or profit form an opportunity and fix it later once things are "more chill", so to speak. If you don't repay the debt, your code gets messier and messier and adding new things or changing existing things becomes harder and harder. That's when you need to think about repaying technical debt or do some long overdue modification that's sitting in the backlog.

To provide an example, say you decide to take on technical debt in some part of the application to chase an opportunity. The code is such a mess that you can't look yourself in the mirror anymore. So you create a backlog task of "Clear up the mess and write a proper implementation" to clear up your conscious later. But with the mess you take advantage of the opportunity. And then you discover that you don't need to touch that part of the application anymore and it doesn't affect adding new features or changing existing ones. What do you do? This is really a huge mess compared with other technical debt tasks in the backlog. So do you work on this or on something else? Put another way, do you clear up the mess or leave it like that?

And most of the times the answer is, you leave it like that. It's isolated in one part of the application you won't work on. It's not something that slows you down on the things you are doing next.

To give an analogy, unpayed technical dept is like walking out into the sea. The first feet are OK, the ground is solid, water is up to your knees. But go further along and your feet are no longer on solid ground, water is up to your head, you struggle to take a breath. You can walk in the sea with water up to your knees indefinitely, but when you are in over your head that's the point you need to turn back. It's the same with technical debt. At that point you need to repay it. Look at what's preventing you from making progress and you will then know what to fix now, and what can wait for later.

It's usually a combination of three things:

  1. frustrated developers who notice the difficulties in doing their job;
  2. conflict between developers and managers (i.e. managers want something done within a timeline, developers complain they can't because of <insert specific technical debt here >)
  3. an increase in defects because of a reoccurring cause or the need for extra trials to make something work instead of getting it right the first time.

Being mindful of your technical practices and business decisions, and keeping track of those three points will give you the information you need to prioritize your technical debt tasks.

In ending, I want to make a distinction between technical debt and plain mess of the code. Taking on technical debt is a (mostly business) decision, to sacrifice something now for a gain, and fix it later when you have nothing else to loose. Technical debt is not a mess caused by bad practices, incompetent developer, lack of skills, etc. That's just a mess. And it's not solved by prioritizing tasks and fixing them, it's prevented by using good practices, working on improving everyone's skills, doing code reviews, refactoring, etc.

2
  • Thank you for pointing that out, but I feel it misses the point of the question a bit. To stay with your metaphor, the question I'm asking is: What is a consistent and stable way to judge the depth of the water I'm currently walking through? – Michael Große Jul 15 '20 at 17:28
  • @MichaelGroße: it's usually three things: 1) frustrated developers who notice the difficulties in doing their job, 2) conflict between developers and managers (i.e. managers want something done within a timeline, developers complain they can't because of <insert specific technical debt here>), and 3) increase in defects because of a cause or need for extra trials to make something work instead of getting it right the first time. – Bogdan Jul 15 '20 at 18:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.