
Ask HN: A separate team for fixing bugs? - omidfi
Imagine a team of software developers that its main responsiblity is fixing bugs. Whereas other teams who develope features and shape the architecture.<p>Would it make sense to have such a team? Have you ever seen such a team anywhere?
======
Espressosaurus
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.

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

------
greenyoda
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...](http://typicalprogrammer.com/the-joys-of-maintenance-programming)

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

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

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

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

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

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

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

------
smnplk
No. No.

