The original author of code should fix its bugs, and they should do that before writing more code

There are (at least) the following options that a project manager must make when organizing bug fixes to software:

• Should the original author of the code in question fix the bug? Or should there be a "bug team" who surgically go in and fix bugs?
• Should one fix bugs as one goes along? Or concentrate on features and write the bugs down and fix them in a "bug sprint"?

I am very much in favour of the original author fixing bugs, and fixing bugs as soon as they occur. Because:

• It's difficult to predict how long it will take to fix a bug, e.g. estimates might be "between 5 minutes to 4 hours". It's easier to see how far through the project you are if you have 50% of the features working without bugs, than if you have 75% with an unknown number of bugs each taking an unknown length of time to fix.
• If a programmer makes a mistake, it's important that they learn it, so they won't make it next time. That's why the original author should fix the bug.
• Do you put your best programmers or your worst programmers on bug fixing? Bug fixing is tricky, so if you put your worst programmers on bug fixing they'll only make the situation worse. If you put your best programmers on bug fixing, they'll all quit.
• If one person is maintaining one piece of code, they feel "ownership" over it. This is perhaps the opposite of the desirable quality that everyone knows the code. Nevertheless, I think "ownership" is a powerful concept that causes people to take more care of their work than they otherwise would, leading to a better piece of software.
• Assuming that bugs are fixed immediately, and you find a bug in an existing part of the system, you'll report it and/or fix it. If bugs are left until the end, and you see a bug, you'll just ignore it, as you know there are existing bugs. This might cause a new/different bug to not get reported.
• If you fix something weeks later, you might have forgotten the original code, including weird important speical cases. Ideally everything would be perfectly documented and readable, but that often isn't the case in reality. Having the special cases in your head will prevent your bug fix from actually being an introduction of further bugs.

One of my old bosses used to utter the phrase "you break it, you fix it!". I never had good associations with that phrase, every time I heard it, new pieces of work were only seconds away from being assigned to me :-)