17

The project I'm currently working on has an issue: bugs and tasks are often assigned to people who are too new or too inexperienced and their work ends up producing more bugs down the road. The problem is that parts of our software are much more "dangerous" to work on than others due to code quality issues. I've been trying to combat this issue by estimating the risk associated with tasks and paying close attention to which developers get assigned which tasks.

We use JIRA so I started labeling issues to keep track of this estimation. I've noticed that I've ended up using several metrics to categorize a bug/task:

  • How clear/straightforward it is. E.g. whether it's something that will need a lot of design work or just a simple UI bug fix.
  • How maintainable the affected area of the code is. Is it a well-designed area or a big ball of mud.
  • How much of the program I think will be affected by the required change.

My labels are kind of messy since I didn't have a clear idea when I started what the possible categories would be and I still don't. I'm thinking about requesting a new field be added (something like "Risk") so that we can require an estimate before assigning the work to someone.

Has anyone dealt with this sort of thing before?

0

3 Answers 3

26

One of the failings of most bug tracking approaches is they only deal with one side of the equation - the end user's view of the system. This is a critical bug to fix to this can wait a week (priority), this bug is painful to this is an s in a pluralization glitch (severity).

A blog post describing multidimensional bug tracking looks at addressing this including the developer view: PEF and REV.

The PEF values are the user's view:

  • P‍ain - how painful is the bug when it is encountered?
  • E‍ffort - how much effort does it take to work around?
  • F‍requency - how often does the bug occur?

The REV side is from the developer's view:

  • R‍isk - how risky is the fix?
  • E‍ffort - how much effort will it take to fix?
  • V‍erifiability - how easy is it to verify that the bug is fixed?

Each of these is measured on a 1..9 scale with 1 being low/easy and 9 being high/hard. The numbers are added together to give a score for PEF and REV.

The part that addresses the bits described:

  • How clear/straightforward it is. E.g. whether it's something that will need a lot of design work or just a simple UI bug fix.
  • How maintainable the affected area of the code is. Is it a well-designed area or a big ball of mud.
  • How much of the program I think will be affected by the required change.

These factor into the effort and risk described in in REV.

Yes, it is something that's been fought with before. I have (in the past) used this model for custom fields in Redmine and it was reasonably successful.

The big advantage of this comes in when you compare the PEF and REV scores. If you have a PEF of 21 and a REV of 7, thats something that can be a big win. While a PEF of 7 and REV of 21 is something that should be avoided for awhile because the risk and effort side likely outweigh the benefit fixing it.

One can then look at the REV score and assign things with low Risk to the less experienced developers (low risk, high effort are often ideal for this situation).

2
  • 1
    Thanks, that post is very useful. I'm surprised this hasn't been written about more in books but I'm probably looking in the wrong places.
    – takteek
    Apr 18, 2014 at 17:56
  • @takteek Another bit, that is related to this is lostgarden.com/2008/05/improving-bug-triage-with-user-pain.html which is another approach at specifically measuring the user side of the 'pain' aspect and what those metrics can be used to drive (this generates a 1-100 scale that incorporates all the user side information I'd suggest looking at it too). Note in this the 'temptation to assign "cost"' bit hints at don't include the developer side info in the user side metric.
    – user40980
    Apr 18, 2014 at 18:42
4

I would say that what you are referring to here could better be called 'complexity'. Of course, the more complex a change is the higher the 'risk' is that some new bug may be introduced by an inexperienced programmer. It is not a bad idea to introduce such a field if it is a real issue.

However, judging from what you wrote you seem to have two issues:

  1. You are dealing with new or inexperienced programmers.
  2. The quality of (much/some) of your code seems to be questionable.

In addition to introducing something like a 'complexity' field (which would help to manage and prioritize your work), I would suggest you focus on mitigating the risk of the above two issues.

To address the first issue I would create a process whereby new programmers first discuss all new bugs with a more experienced programmer before working on the bug. Also, I will definitely introduce code reviews to both lower the risk of new bugs being introduced and to use as coaching opportunity for the new programmers to get up to speed more quickly.

With respect to code quality, I would do two things. Firstly, stop the rotting process: agree on coding standards and practices that would prevent any new inferior code from being introduced. The suggested code reviews would help here too. Secondly, I would identify the worst parts of your code and start refactoring and cleaning up these.

1

Yes, it is a good idea not to give inexperienced developers problems that are too complex. But the flipside is that if you only let them do the easy stuff then they won't learn.

I suggest an alternative strategy is to institute a regime of code reviews. Let the newbies work on work on the tricky stuff (within reason), but thoroughly review their work.

In the short term, this is more work for everyone. In the longer term, you will end up with a whole team of developers who can handle the complex stuff, AND are "on the same page" as far as code quality is concerned.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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