Ask HN: A separate team for fixing bugs?

No, 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.

By 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.

In 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.

That 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.

Having 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...

In 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".

No.

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.

This 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.

No. No.

Oh look, a thread about my current company. I'm actually in a bug fixing team right now separate from the main product development team. It's an extremely difficult position because as someone else mentioned, you need an incredibly deep understanding of the system to truly resolve these bugs. Unfortunately I work on a 20+ year old legacy codebase with minimal documentation and poorly written code, and our dev team is unwilling to spend any time helping to resolve these issues. They're too occupied with churning our new features, while the bug team is abandoned to clean up the mess from all this new code without any sort of help whatsoever. Another perspective that many people don't discuss is that only doing bug fixing is soul crushing. With things constantly breaking, it can be very mentally draining having to fix them. That being, the attrition rate on the team is quite high because there's very little career growth or satisfaction in being a bug fixer. This experience could be exclusive to my company, and I can't say whether it's effective for the business to run things this way since I'm still really early in my career.

Why would one want to do that? That looks like an open loop system. Fixing bugs is a feedback loop that allows the system to correct.

I try to involve juniors as new as a couple of weeks in all the project so they learn how software gets made and how the business is run (cc'd in mails with clients so they get the initial back and forth, ideation, clarification and elicitation, how specifications come to be, tradeoffs in engineering and business, courtesy) and I ask them to interact with the client.

Then they write the code knowing the rationale behind why they're writing it this way and why one feature is higher priority than the other.

They then can be more independent because they see a bigger picture than adding a new endpoint.

Then when there's a bug, they know about it first hand and they witness how it's handled with the client and they go on to fix it learning and documenting the assumptions that lead to the bug.

Alignment is high, as is accountability and the desire to make it right. Learning is accelerated in terms of engineering and code, communication, and business savvy.

In my opinion, one misses so much separating concerns that way. Even the humility would go down as the one who wrote the code doesn't get the feedback from the mistake.