DEV Community

Jonathan Hall
Jonathan Hall

Posted on • Originally published at jhall.io on

Reader question: Should we have a bugfix team?

Fellow reader Anita Kalmane asked: “What’s your opinion on having a separate team who is fixing bugs?”

I want to share my response, slightly edited for brevity:

I think it’s a terrible idea, except maybe as a VERY short term measure in an emergency.

The three biggest reasons:

  1. It teaches the team producing bugs that “bug fixing is someone else’s problem.”
  2. It has the bugfix team working without proper context.
  3. Usually companies that do this put the “least skilled” (however they determine that) people on the maintenence/bugfix team. This means the bugfixers never get exposed to the rest of software development (designing systems, etc), so it becomes a sort of a dead-end position.

Top comments (3)

Collapse
 
kevinhickssw profile image
Kevin Hicks

This could also depend on how you set up the separate bug fix team too. I wouldn't be a fan of a permanent bug fix team that is always the same people. I'm also not a fan of project and maintenance teams where one team does the architecture and initial build then hands it off to a team that adds new features and fixes bugs.

However, I am a fan of rotating bug teams that are made up of people from the larger team working on the project. Every few days or weeks the team would take some people off features and maintenance to handle bugs only.

Doing it this way counteracts most of the drawbacks you mentioned while providing the benefit that on a day-to-day basis most developers don't need to context switch as much. Instead of needing to hop on a bug immediately when deep in a feature, another dev who is only fixing bugs that day can jump on it. Then a few days or a week later those devs may switch spots. This also helped promote knowledge passing and devs got to learn more about areas they may not work in a lot instead of one dev always handling everything for a single feature.

Where I have seen this done we also normally kept people responsible for their own bugs if the code was just deployed recently.

Collapse
 
jhall profile image
Jonathan Hall

In my view, the ideal situation (not always possible) is for the developer who introduced the bug to do the fixing. This allows them to learn from whatever mistake lead to the bug, to improve and not make the same type of mistake in the future.

If they do bug fixes on a set day of the week or something, that may be fine, from a workflow perspective.

But I think even a rotating "bug team", as I think you're describing, is not ideal.

Collapse
 
kevinhickssw profile image
Kevin Hicks

I agree it is ideal to have who introduced the bug fix it or at a minimum a post-mortem so they can learn from the mistake. This is why for recently deployed code, the developer who touched that area would be responsible

Where I have seen this used, most of the bugs handled by the bug team were months to years old code that was just discovered to be an issue. Sometimes we could tell who caused the bug, but often it was 5+ developers who touched the area and you wouldn't know who broke it until the fix was ready and you knew the exact cause.

We also got several "bugs" on the bug teams that were stakeholders changing requirements or not understanding how something worked that needed to be "fixed" urgently. Not an ideal situation, but you can't always push back and need to choose your fights with stakeholders sometimes.