This seems more a failure of your code review process than who is fixing the bugs. If the

anti-patterns in the code and faulty assumptions that don’t get reworked

aren’t getting called out and corrected before the change is merged independent of whether this is a bug fix or the initial implementation, you have bigger problems than whether developers are fixing their own bugs or not.

For recent bugs, I agree with the other answers. Most of those are sorted out in the pull request process and it’s a matter of pride and familiarity to fix your own bugs.

However, there are scaling issues with longer-term bugs. The most experienced developers have touched the most code simply by virtue of being there the longest, so you need to transfer ownership to spread the work out. Likewise when someone leaves or joins the company.

Additionally, it often requires more skill to fix a bug than to create one, especially when you get into tricky areas like concurrency. Senior developers tend to get the trickiest bugs escalated to them, and in order to have time to tackle them, need to delegate some of the easier bugs.

If you maintain strict long-term ownership, senior developers end up overwhelmed by volume and junior developers end up overwhelmed by difficulty.

First, to make this formally an answer, here are some possible reasons why the developer should fix their own code:

• They wrote it, they understand it best, they need the least time to fix it.
• They made a mistake, they should be punished for it. To make it explicit after some comments: this is written somewhat tongue-in-cheek, and I wouldn’t agree with such a rule, but there are managers in the wild who might assign tasks according to such reasoning.

However, there are some negative aspects which should also be considered:

• The bug may be caused by a fundamental misunderstanding, and the “fix” only patches the symptoms.
• The original author may be unavailable (vacation, sickness, urgent work in another project, job change). Ever heard of “bus factor”? If only one person knows and understands the code, your bus factor is 1, which is something to avoid.

There’s a quite different approach which should at least be considered, even if your organization isn’t willing to adopt it dogmatically: Collective Code Ownership.

In an extreme interpretation, it demands that every developer should be able to pick up and work on code written by another, including when bugs need to be fixed. The extreme isn’t always achievable, and that is often used as a straw man argument that collective code ownership can’t work. There also is the hidden implication that developers are easily replaceable, which in reality they aren’t.

However, if you consider a moderate version of collective code ownership, there may be some advantages:

• Agree on a number of coding conventions, from formatting to use or avoidance of certain language idioms. This makes code often better readable to other team members, including new developers.
• Do code reviews not only to find mistakes, but to understand what a piece of code does and gain shared knowledge.
• When bugs are analyzed and fixed, pair programming (preferably including the original developer) can be helpful even if you don’t do it for regular development, as two pairs of eyes often see more, and communication about the cause of a bug helps both people involved to get a better understanding.

You wrote

I see a lot of anti-patterns in the code and faulty assumptions that don’t get reworked

but I challenge your idea of that being caused by “developers fixing their own bugs”.

When anti-patterns and faulty assumptions don’t get reworked in your team now, the situation won’t improve just by making devs fixing more of other developers bugs. Quite the opposite, when I have to work on code not written by myself, I suspect myself to lack some understanding of the surroundings, which the original author might have had. This can make me make even more hesitant to change more than the bare minimum necessary to close the bug ticket.

More generally, bug fixing is IMHO the wrong point in time to refactor (at least it should avoided to do both within the same commit). Removing anti-patterns and fixing “wrong assumptions” beyond the ones which were causing the bug should ideally be done at a separate point in time/commit. Better points in time are:

• immediately after one added a feature, when code was extended and became less clear by this extension

• before adding a feature, to make this task easier

• before or after fixing a bug (but not at the same commit, and regardless of who was the author of that code section!) – especially when the bug fix isn’t just fixing an obvious typo

• during code reviews (as Philip Kendall already wrote)

So in short, who fixes whose bugs and code quality are usually unrelated issues.

Still, in your situation, I think the bug fixing process can become a starting point for improving the code quality and introducing more code reviews: try to convince the team to have each bug fix reviewed by a second pair of eyes. Bugs often come in clusters, and code sections affected by a bug are often worth a second look. Hence the focus for such a review should be on identifying related bugs and letting the reviewer make suggestions for code improvements which prevent to happen this kind of bug again. The original author of that code section – if available – can either be the one who fixes the bug or the one who reviews the fix.

That way, you can satisfy your team’s idea of keeping the author of a certain code section informed as well as your idea of getting the code quality improved.

In addition to Philip’s answer I would like to add that it can be quite demotivating when you do not get to fix your own bugs. Maybe not when it’s a really small thing like inadvertently writing == instead of != but certainly when the next person decides to go about it in a totally different manner.

Cooperating in the same code base requires respecting each other’s work. If something is wrong or missing I would prefer a new issue being assigned to the same person allowing them to dot their i’s and cross their t’s. This respects their work and has them learn something so they will do better next time.

The question is stated as a yes/no question, but the real answer is “it depends”. Sure, if there is a bug in code which I wrote last week and which got deployed this morning, I am probably the most suitable person to fix it, as the code is new enough that I’m the only person familiar with it.

But a bug in code written five years ago, and which only surfaces now because it now gets called in a way which triggers the bug? The original developer may not have looked at the code for years. Heck, the original developer may not be employed anymore. What are you then going to do with a policy of “developers fix their own code”?

What are you going to do with bugs which is caused by the interaction of five different systems, each with their own developers? It may take a long time to pinpoint the bug — might as well fix that bug when you find it instead of tracking down the original developer and tell her what to fix.

If there is one thing I learned in 40+ years of coding, it is that there are no absolutes. There’s no “one size fits all”. “Developers fix their own bugs” isn’t a policy that’s always going to work. Neither is “Bugs get fixed by others”.

Yes, developers should fix bugs in their “own” code. But developers
should also fix bugs in “others” code. I’m using quotes here to
emphasize that most developers doesn’t own the code they work on – the
company does – and feelings of ownership are illusory and may be
harmful.

Because in my opinion the core problem here is in the word
“own”. Having developers feel that they “own” code have advantages and
disadvantages. The advantages are that it is clear who is responsible
for maintaining some piece of code. That person may also have some
freedom in how they want to structure the code as long as it works and
as long as it adheres to established style guides. Whoever is
responsible becomes a specialist and is is clear who should be able to
answer other developers questions about the code.

But there are disadvantages too. Developers may shy away from fixing
bugs in “others” code for fear of stepping on someone’s toes. Perhaps
they’ll write a bug report instead, but this introduces bureaucracy if
the fix is relatively simple. It can also reduce code quality if the
developer who “owns” a module is weak and unable to maintain it
properly. A stronger developer may notice that the bug fixes are just
band-aids, but be unwilling to do anything about it since it’s not
“their” module. Ownership can also cause problems for the company if
the only developer with deep knowledge of a module quits.

In my opinion, the disadvantages far outweighs the advantages. The
whole development department/team/group should “own” and be
collectively responsible for the codebase — not individuals. It’s
better if everyone has broad, but shallow, knowledge of the codebase
and thus are able to collaborate than if everyone is a specialist, but
with no understanding of what others are doing.

Of course, collective responsibility is hard to achieve in practice
and developers (in my experience) naturally takes on “ownership” of
the code they produce. However, in my opinion, development processes
should de-emphasize this tendency which means that developers should
be encouraged to fix bugs in code written by colleagues.

There is more nuance to this question (and answer) than the question title suggests.

Rogue devs

Your core complaint is that when there’s not enough eyes on the code, one dev is able to go rogue without anyone being the wiser. I agree that this is a problematic situation and there should be general team consensus on the work that is being delivered, to ensure that one person does not write things “their” way.

However, having people fix other people’s code from the get go is an inefficient way of doing so. A code review is a much better approach here.

You’re putting too much on the second person there. Yes, by forcing them to fix the bug you innately force them to understand the code, and with a code review someone could claim to have reviewed the code and not actually have done so, but that’s no longer a discussion on what developers should do, that’s an issue with your employee’s work ethic.

Ownership

Let me put it differently. If others always fix someone’s problems for them, then how are they ever supposed to learn that what they’ve been doing is incorrect? And even if they figure that out, what incentivizes them to not do so in the future, since they’re not the ones having to clean it all up?

True ownership means you remain responsible for the decisions of your actions. You did it badly, you therefore have to now redo it. Obviously, this is assuming that the person is capable of the required fix – don’t send a junior up sh*t creek without a paddle to implement senior level code.

Team ownership

That being said, team ownership also factors into this. If the original dev is otherwise indisposed and not easily available (whether absent from work or having other commitments that cannot wait), it’s perfectly reasonable for someone to help get this feature across the line.

Similarly, there is a (not pedantically defined) statute of limitations on a single person’s ownership over the work. If the buggy code has been part of the system for some amount of time, anyone can now look at it.
Developers should not carry code in perpetuity. They should carry it during the development stage and it gets inherited by the broader team at some point (this is contextual when it is appropriate to do so).

Conclusion

• You’re pointing at a valid problem but are using the wrong solution to try and fix it.
• In order to get more eyes on the code and prevent rogue devs, institute a code review process.
• If devs are rubberstamping the code reviews without proper reviewing, this either means that they’re not trained on how to review code, or they have a problematic work ethic. In either case, it is not the review itself that is causing the issue.
• Devs should exercise ownership over their work, and when they make mistakes, cleaning up their own mistakes is a great learning tool that should not be ignored.
• Where reasonable, the team still owns the work and members should be willing to take on any of the team’s tasks. If the bug has existed for some time, the dev is indisposed, or it requires an expertise that the dev does not have, of course it is sensible to involve another dev at that point.

In addition to the good points made in the other answers, determining the relative productivity of developers is more difficult when they are not fixing their own bugs. I’m not saying it can’t be done, but that it requires more rigorous tracking and analysis.

If you have every developer fixing their own bugs, the amount of (roughly equivalently sized) features that a sloppy developer can produce will be less than one who is writing code at a more optimal level of care and/or using better techniques.

That is, if a developer is trying to close out as many items as possible and bugs are distributed to the team as a whole, they can artificially increase their throughput by churning out defective code or in technical terms: ‘crap’. There’s an opposite issue where developers can be too worried about creating defects and become too careful. That’s why it’s important to focus on the throughput of working features to production and not the amount of (non-production) defects.

If you push the defects back to the developers, it creates a natural feedback loop and they can learn to optimize their productivity with limited additional information. If you don’t do that, it means you need to track the defects and who created them over time and then communicate that back to the developers who are creating excessive defects. This is problematic for a few reasons but the biggest is that it may cause the developers to try to minimize defects to avoid being ‘blamed’ for them instead of optimizing for throughput. If this tracking isn’t done, the management (lead etc.) can easily mistake their least productive developers as the most and vice-versa. The best developers will tend to become disgruntled by this situation and may quit.

The side benefit is that it’s also much easier to see which developers are truly the most productive and reward/promote them accordingly. The thought of trying to track and attribute defects and then find the optimal rate seems pretty daunting and I’ll assert that it probably requires some guess-work. It’s also unlikely that most developers will know use that feedback to achieve the real goal (i.e.: working production features) directly.

If you have a situation where one developer is so bogged down by their bugs that they can’t get out from under them, you may need to distribute those defects to other team members. However, this would be a clear indication that you have a developer who needs support and/or mentoring and (unfortunately) may not be able to perform their job adequately. Obviously, if you let someone go or they quit, the rest of the team will need to fix whatever defects they left unresolved.

NOTE: I need to make it clear that I am talking only about bugs found in during development and testing. Production defects are a failure of the team/process and attributing them to a single person is highly misguided and (somewhat paradoxically) tends to lead to more production defects. The question of how a defect got into production without detection is much more important than how it was created.

P.S. I think this is being misinterpreted. This is not about punishment. It’s about feedback loops and letting developers ‘manage themselves’. As an analogy, there’s a condition that certain people have where they feel no pain. While initially, this might seem like a good thing, it’s actually a really big problem. No one wants to suffer through the pain of being burned but these people can suffer from serious injuries where they (e.g.) place their hand on something very hot and have no idea they are getting 3rd-degree burns until they smell it or see smoke. Having your defects come back to you is like that immediate pain feedback most people have. You learn of the error you made much closer to when you made it. This allows you to correct and learn much more efficiently.

A bug is a deviation from wished, expected, or specified behavior or state. Bug fixing is implementing a new (wished/expected/specified) behavior or state. The only thing that the word “bug” adds is a negative attitude to the old behavior; however, technically, bug fixing is simply the process of implementing a requirement (for software at least, as actually removing insects from hardware is manual labor).
So your question is simply whether the same developers should continue working on implementing a requirement concerning a piece of code they worked on before. Here are my answers:

• For a good developer and good code: yes.

• For a good developer and bad code: the developer has probably improved in the meantime, but still, determine first why the code was bad before taking any decision.

• For a bad developer and good code: something went wrong in the meantime with the developer, so give the code to a good developer.

• For a bad developer and bad code: give the requirements to a good developer and ask him/her to write the program anew.

(Naturally, it’s sometimes hard to determine the quality of the developer and the code. In such cases without full information, it’s hard to give a good piece of advice.)

I think that this question is really about the amount (if any) of help that you as a junior developer get from the testers on how to correct bugs identified by them. I trust that you appreciate that the essential sense of why bugs found by reviews of X’s code (or indeed in the code allocated to X for maintenance) should be fixed by X: how else may X learn to write less buggy code ?

I say this as the phrasing of your question suggests an allocation of bugs to developers but no mention of how to write the bugged code better is passed on to the coder in your company. Just sending problems back to its coder without good feedback is useless.

A facet of many of the more recently established software companies is that junior developers are given little or no guidance. For the most part they are left to get to grips with the software system, the company’s stated and unstated preferences in coding, the customer’s needs and everything else all on their own. Some companies almost seem to intentionally create a Darwinian situation where it’s every coder for him/herself and no help or mentoring is offered to new employees.

Maybe this is sometimes for saving money on software tester time/salaries – which cost much more than developer time/salaries. But maybe there is also a sort of predisposition among those ex-senior developers running such companies that disdains the human communication side of mentoring and training junior staff. Or disdains the concurrent need to listen to other perspectives from the junior staff – some perhaps a lot more potent than those applied in the company’s existing code base.

But at any rate this no-guidance/DIY management is a fact of life within many software companies today and, despite the notable success that some tech companies implementing a better expertise <-> action/observation exchange process, this trend seems to be unchanging.

If I were you I would seek out a dev job in a company with a more positive approach to low-key mentoring of junior staff, even if this means working on a software product that is less “exciting” than others. That way you will learn your software engineering craft better. And, with the good example of senior devs/testers around you, you would also become a more inspiring developer yourself.