15

We're using JIRA to keep track of issues in our software projects. One effect we noticed is that we often create a new issue but we don't knw yet when/if the problem is going to be fixed at all. So we invented a fake 'Distant Future' milestone which such issues get assigned to.

As it happens, the pile of issues assigned to this milestone keeps growing all the time so it seems this is not a good approach. There are so many of them by now that it became quite a lot of work to review all of them for validity. Some of them became invalid since the component they are related to you was removed. Some of them were duplicated by other issues. Some of them have such a poorly phrased description that nobody really knows what they are about anymore.

How do other software development teams deal with issues which are valid, but which might not get fixed anytime. Do you bother recording them at all? Do you assign them to the next planned version and then look at them again as the next release approaches? Something else?

Frerich Raabe
  • 329
  • 1
  • 7
  • 1
    Looks like you are talking of my workplace, very disturbing. Good luck with that, I'm lobbing for a while now with and get slow to no progress on that point. Management seems to not bother until we have so much garbage that we can't ognore it anymore. – deadalnix Oct 13 '11 at 09:49
  • Why does it need to be fixed? If it is not important and never gets fixed then that is perfect. – B Seven Oct 13 '11 at 22:31

6 Answers6

11

These are good first contact bugs to fix for new developers that have just joined your company. Or for junior developers to expends their knowledge of the system.

If not, you can mark them "wont fix" if they are not serious enough to justify the time it would take to fix.

Sardathrion - against SE abuse
  • 3,706
  • 3
  • 19
  • 34
  • The 'first contact bugs' idea is not bad; somebody else already suggested something like this, calling them 'Janitor Jobs'. – Frerich Raabe Oct 13 '11 at 09:33
  • 3
    +1 For won't fix, it can be a social problem as well as a technical one. Sometimes you just have to say NO. If you keep fixing bugs, particularly trivial or superfluous feature requests peoples expectations will rise and they'll keep asking for more. – Benbob Oct 13 '11 at 09:41
  • 4
    Having junior programmers fix bugs is a bad idea, unfortunately this is a widespread practice in the industry. The most cost-effective way of fixing a bug is letting the developer that introduced it fix it. – Trasplazio Garzuglio Oct 13 '11 at 09:42
  • 6
    @MarcoDinacci - It depends on what you put in "cost-effective". With a short term view you are correct. But if the project lasts long, giving 'fix bugs' assignments to junior programmer can be seen as an investment. – mouviciel Oct 13 '11 at 09:52
  • @MarcoDinacci: A code review before commit allows more senior programmers to review the code and teach (if any need is present) the junior programmers. Besides, whoever wrote that code may have left. – Sardathrion - against SE abuse Oct 13 '11 at 09:53
  • 2
    @mouviciel I think there are better and more stimulating ways to train junior programmers than let them work on bugs but I do agree that it is a way to learn the codebase. Another problem with this approach is that senior developers may end up just writing code not caring for introducing bugs because there are the junior developers that will fix them anyway. – Trasplazio Garzuglio Oct 13 '11 at 09:56
  • @MarcoDinacci: I think here the term "bug" is used in a general sense, not necessarily as a defect in the code, so there would be no "programmer who introduced it". – UncleZeiv Oct 13 '11 at 11:24
  • 1
    @MarcoDinacci, if senior developers write code not caring for introducing bugs, the team has a way more serious problem than unresolved JIRA tasks, with or without juniors. – Péter Török Oct 13 '11 at 12:55
  • @PéterTörök of course, which is why senior devs should be responsible to fix their errors, not giving them to somebody else. – Trasplazio Garzuglio Oct 13 '11 at 13:06
  • 3
    @MarcoDinacci, let me put it differently: if senior developers need an external process to force them to produce quality work, the team has a fundamental problem. IMHO any good developer - but especially seniors - ought to have an *internal* motivation for quality. If that motivation is lacking in the opinion leader(s) of the team, the project will almost inevitably fail, one way or another, and no amount of process can help it. – Péter Török Oct 13 '11 at 13:54
  • @PéterTörök I totally agree with you. Unfortunately, not every dev has the internal motivation for quality you're talking about. Letting them slack by giving the issues they're responsible for to somebody else only worsen the situation. – Trasplazio Garzuglio Oct 13 '11 at 14:02
  • @MarcoDinacci, it depends on the personality too. Some people are happy to let others do the dirty job, others hate to expose their mistakes (especially to juniors). Assigning their bugs to someone else to fix may be a strong motivation for the latter type to improve the quality of their output. – Péter Török Oct 13 '11 at 14:36
11

You should fix a bug only if the application is more valuable without the bug.

If a text field is misaligned and it takes three days to fix it, then the cost is probably too high and you should leave it. On the contrary, if the users cannot write at all into the text field then you should fix it, and quickly.

In general it is easier to fix an issue immediately after it has been discovered. If you let time pass, developers may forget how that part of the code works and fixing the bug will take longer and therefore will be more expensive.

Some companies don't write a line of new code if there are still bugs pending. Others don't bother until the testing phase before delivery.

In your company you are obviously letting to much time pass before fixing new bugs so they're accumulating. It is also bad for the morale of the team to see a huge list of bugs.

I suggest you to spend a day just to sort out the existing bugs, deciding the ones that are worth fixing and the ones that are not and assigning the ones to fix to the existing team members with the goal of resolving the issues before the next milestone.

Trasplazio Garzuglio
  • 1,740
  • 9
  • 18
6

In our issue-tracking, there is a status "time-barred". If an issue is several months or even years old, and no client urges or refiles the issue, then this status is used as the final status. This is not done automatically, but manually, whenever the managers ask us to clean up the open issues. During this process, it's also likely that some of the issues are fixed because they are easy to fix and/or relatively important (despite not being urged or refiled).

user281377
  • 28,352
  • 5
  • 75
  • 130
  • 1
    This is a good strategy - knowing a bug that has nagged at you for years might get swept under the rug forever is a great motivator for tackling it. – Steve Jackson Oct 13 '11 at 21:49
2

I don't use JIRA, I've got fogbugz at work but I'm sure this applies to most bug trackers. While writing this I realized that the way I work is more agile than waterfall, deadlines are not concrete for me and what matters is priority.

  • If your boss cares about too many tickets being open just don't create the trivial ones in the first place. You should be prgamatic and not add any features/fixes that have no benefits. If it will make your life easier to polish some code or tweak the UI then sure, add it. Don't just make work for yourself by trying to fix minor flaws in the product, nothing is perfect.
  • Put the unimportant bugs/features in the current milestone but under a low priority. If more complaints/requests are mentioned about the issue then you can bump up the priority.
  • Close/resolve what you can as won't fix, can't reproduce, duplicate etc. Some bugs are too trivial to fix or they are feature requests that would take far too long. Sometimes you just need to tell the person requesting these fixes/features "No Sorry, we don't have time".
  • Prioritise the bugs as required and have your ticket list sorted by priority and milestone.
  • If they are not going to make the milestone then move them into a future milestone.
  • If a ticket is dependent on some other ticket being completed then mark it as blocked or organise the tickets into a hierarchy so it's obvious that ticket-x and ticket-y are related.
  • If a ticket requires some feedback from someone assign it to that person.

Ultimately you will always have a bunch of low priority tickets sitting about, but points above should help you minimize that.

Benbob
  • 1,216
  • 9
  • 22
2

We use JIRA, and have an additional resolution state called Suspended -- if a feature/bug is something that we just have to give up on for a while, it gets resolved as Suspended. That way it doesn't get mixed up with either the list of currently active issues that we have to keep our attention on, or the list of resolved issues that we know have been handled satistfactory, and it's still in the database.

The list of Suspended issues is something that I review periodically (but not very often) to reopen as necessary.

Jason S
  • 795
  • 1
  • 5
  • 10
1

Not sure of the correct JIRA terminology, but consider putting an expiration date on each "ticket". If it has not been escalated, by feature needs or bug severity, to implementation within a certain amount of time, it probably wasn't that important in the first place. This should help automatically keep the pile trimmed. I often get tickets based on "wouldn't it be nice" or "this doesn't work perfectly like I want". If no-one else pushes enough for it, or that user doesn't have enough clout, it doesn't get done and I close the ticket after a couple of months.

cdkMoose
  • 1,775
  • 9
  • 12