Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Let's assume the situation where a team of four developers is building an application. During the testing phase, bugs are reported by users. Who should fix them? The person who committed the erroneous code, or anyone who is free?

What is preferred approach in agile development (scrum)?

share|improve this question

migrated from pm.stackexchange.com Feb 25 '11 at 15:14

This question came from our site for project managers.

3  
He whom hath created thy code should fix thy code –  Agile Scout Feb 25 '11 at 16:29
add comment

11 Answers

up vote 29 down vote accepted

The preferred approach in agile development would be to get them fixed as quickly as possible, by whomever is available. This is simply because the ownership of the code does not fall to any one person, but to the entire developer group. If one individual is consistently causing bugs, that is another issue that needs to be addressed separately.

share|improve this answer
1  
+1 for "as quickly as possible". Indeed, fix them as soon as you can and let your users to continue testing, and report new bugs. –  yegor256 Feb 24 '11 at 21:05
1  
And what about feedback to the person who commited the bug? –  Robert.K Feb 25 '11 at 7:26
    
@Robert it's not a matter of just feedback. The bug has to be formally closed by the submitter. –  yegor256 Feb 25 '11 at 7:52
8  
Also fixing other people's bugs is a great way to learn. Because you didn't write it, it forces you to really understand what the code is doing. –  AndrewKS Feb 25 '11 at 16:06
1  
@yegor, robert asked about the person who wrote the bug, not the submitter. For important bugs it should be reported, for trivial ones not. –  user1249 Feb 25 '11 at 20:05
add comment

In my team, we always decide according to priority. if the person who submitted the code is available, he/she fixes the code. If that person is working on some higher priority story, anyone who is available and can fix the code as soon as possible will fix it. If everyone is busy with working on higher priority tasks in the current iteration, the fix is scheduled in the next iteration according to its priority as compared to the other stories and defects.

share|improve this answer
add comment

There are only three reasons to care about who fixes a bug: cost, speed and professional development.

And there are pros and cons for all three. For instance professional development, on one hand it's an opportunity to learn more about the code on the other it's an opprtunity to recognize the kinds of mistakes you make and avoid some in the future. Or take cost, presumably the one that made the mistake would be able to fix it faster, and probably cheaper, on the other hand there's a cost for the time spent identifying who made the mistake, and assigning it to the appropriate person -- time which in a lot of cases exceeds that of fixing the bug.

The agile approach is to let the developers self assign the problem, I would override that only for a good reason.

share|improve this answer
add comment

When a bug is found, it is the responsibility of the whole development team to fix it.

If people believe that a bug should be fixed by its author, it is like saying "I'm not fixing the problem, the hole's not on my side of the boat". But the boat will still sink if the hole is not fixed, and you are on that boat with everyone else.

Individuals need to realize that they are part of a team and understand that the code, along with its responsibilities, belongs to all of them. The success of a project rests on all team members.

share|improve this answer
add comment

I say, you need a bug tracking system, to record bugs, caused by what, reported by, and then assign the bugs, to different people based on their work load. Also indicated whose code caused the bug, and then have a report showing how many coders, and what apps, have caused x number of bugs during the week.

Then you can show that to coders, to show how they are causing bugs.

And the best way to prevent bugs, is to get everyone involved with fixing them. I mean assign a bug fix to different people, to give round-out experience of what causes bugs and what fixes them.

Then maybe after a month or two of everyone fixing bugs, revise or create your coding style guideline to help prevent future bugs, system wide, by having written/documented standards for how you program.

share|improve this answer
add comment

I don't know how scrum handles this scenario, but in my team, we have something like a cross testing / code review. This way, in case a bug is found, both the developer and reviewer discuss the best approach to fix it.

I believe that, as long as the solution fits, does not matter if the developer or reviewer applies it. Is important however, to avoid any kind of conflict between developer and tester.

Rgds

Edit: Not sure if I made myself clear, but is important to highlight that the reviewer is another developer in the team.

share|improve this answer
    
@Tiago: I appreciate your solution, but I don't think the discussion is always necessary. –  Hoàng Long Feb 25 '11 at 7:08
add comment

Think about: Who has more information about the bug? The development team.

So let they decide what to do with the bug. They own the code, so they are responsible for it.

You can help them by managing the project, allocating some time on project scope for bug fixes and letting they alone to do the job.

Avoid taking to many decision where you (as PM role) has less information than the team.

See the question about: How to Avoid Micro-Managing a Software Development Team?

share|improve this answer
add comment

I totally agree with Steven about the code belongs to all team; and there's some more reasons that you shouldn't give the bug to their creators:

As I know, in many cases it's hard to identify who caused the bug. Even if you are using a document management system like SVN, tracking down the error code may consume lots of time. So, in my view, just give the bug for anyone who are free.

If you want to track how the bug produced, in leisure time you can ask the repairer about the case (before all team). As your team is small, I think this would share the experience about possible bugs, and not make anyone embarassed.

share|improve this answer
add comment
  1. Evaluate the bug
  2. If it will be faster/make more sense for the original developer to fix it, give it to them
  3. If it can be fixed by anyone on the team, let anyone do it.
share|improve this answer
add comment

As a PM I would avoid linking bugs to specific developers. If it needs to be done let the functional/development manager do that. Concern yourself with the team. There is a bug the team needs to fix.

share|improve this answer
add comment

By default the person. The reason is quite simple: feedback. Bugs provide a great opportunity for personal and professional feedback. If someone else fixed my bugs, I would make the same mistake again, because I wouldn't learn from it.

If that person is not available, somebody else can fix it, but the person should follow the bugs life cycle.

share|improve this answer
    
+1 The Bug-Originator should learn from the bug –  k3b Feb 25 '11 at 10:18
3  
That is why communication is important. If a person who fixes the bug who is not the original coder explains what the problem and fix was to the originator, then two people learn from it, rather than one. –  AndrewKS Feb 25 '11 at 16:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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