Imagine a team of software developers that its main responsiblity is fixing bugs. Whereas other teams who develope features and shape the architecture.
Would it make sense to have such a team? Have you ever seen such a team anywhere?
Ask HN: A separate team for fixing bugs?
1–10 of 12 posts
Re: Ask HN: A separate team for fixing bugs?
#2No, and no. Remove responsibility for code quality and you remove the incentive for building high quality code in the first place. It can (occasionally) work to have an antagonistic testing team (see development of the Space Shuttle software) but only in very specific situations, and there the development team was trying to not let any bugs slip through to testing in the first place.
Re: Ask HN: A separate team for fixing bugs?
#3By dividing accountability between two parties, you end up removing accountability all together.
Bug happens in production. Dev team blames testing team for not catching it. Testing team blames dev team for creating it. Nobody wins.
Re: Ask HN: A separate team for fixing bugs?
#4In my company we had exactly that problem. We first switched the sprints (2 Sprints only features, 1 sprint only bugs for the whole team), but that was unsuccessful, because the whole team were to many people to deal with bugs and bugs took too long to fix.
Usually we do pair programming in feature sprints, but this also did not work out really well for bugs all the time, since most of the time bugs are minor things to fix and should be reviewed and tested by another person.
Then, we tried to split the team into 2/8 or 3/7, while 2 or 3 people are responsible for bugs and the rest for features. That seems to work pretty well so far and is flexible enough, especially, when 3 people work in the bug team - so difficult bugs still can be fixed in a pair, if it is necessary.
BUT: The developers of the feature team and bug team switch in every sprint and the bug team works together with the feature team and is in the same office, the stand up is free for all team members to join in every direction.
Re: Ask HN: A separate team for fixing bugs?
#5That sounds completely crazy to me. Any complicated system is going to have subtle bugs that require deep understanding of the system to identify and fix. A team that just fixes bugs will not have the same deep understanding of the system and at best will take significantly longer to find and fix the bugs than the team that created the system. At worst they'll never figure it out and create churn without solving the problem.
A separate testing team makes sense, but I wouldn't expect them to fix the bugs.
Re: Ask HN: A separate team for fixing bugs?
#6Having a separate team of "maintenance programmers"[1] who fix bugs is a decades-old idea, and I worked in an environment like that years ago.
I think it's much better for the original developers to have the responsibility for fixing their own bugs, since it gives them the incentive to be more careful when writing and testing their code. Not allowing them to write new code until their known bugs are fixed puts the brakes on impulsive developers who churn out unreliable, poorly-tested code quickly.
Also, people who fix bugs in other people's code tend to have a worse understanding of the code than the original authors. This pushes them into making microscopic fixes that address the symptoms of the currently-reported bug, but may introduce new bugs. In contrast, the original author might have the knowledge to rewrite a larger part of the code in a way that fixes many related bugs and makes the code more reliable.
[1] http://typicalprogrammer.com/the-joys-of-maintenance-program...
Re: Ask HN: A separate team for fixing bugs?
#7In a lot of organizations there are "bug teams", whose job is to detect bugs, fix some, and make fixing them easier. However, you probably don't call them "the bug team". Examples:
Site reliability. If devs ship a bug, the site reliability team will mitigate the damage and probably ship out a quick fix. They'll also make it easier for the original dev to provide a long-term fix.
Quality assurance. They find bugs, including more vague user experience bugs. In a sense they can fix bugs by delaying deploys and disabling buggy features.
Security. Part of the security team's job is to identify vulnerable packages and upgrade them, as well as find and fix vulnerable endpoints. Often this won't come back to the original developer at all unless they made a serious transgression.
So bug teams do exist, but usually with a spin on it. The conversation is not "we are separate; your mistakes are not your problem", but "let's work together to make your mistakes less costly".
Re: Ask HN: A separate team for fixing bugs?
#8No.
I don't even want to imagine what a team of developers would turn into if they didn't have to fix the bugs of the stuff they write and kept continuously building "shiny new things".
Also, this would turn ugly (violent) pretty soon in my opinion.
Re: Ask HN: A separate team for fixing bugs?
#9This can happen in orgs that do project-oriented development pursuing business objectives. Maybe one team of devs madly tries to ship some new functionality to hit a deadline. If it is not possible for the organisation to get those teams to prioritise fixing the stuff they already shipped, maybe another team with different priorities gets created to do it.
This is probably a symptom of incentives not being structured appropriately, or orgs that only believe in the existence of projects, not the existence of products or systems that need to be maintained.
Re: Ask HN: A separate team for fixing bugs?
#10No. No.