Comment by Asooka
2 years ago
We review each other's code before it goes in. If the team says they're happy to work with it, then I've fulfilled my obligation. I am literally not paid to write the best code in the world. In fact, the company gives bonuses for fixing things, so they are in fact paying me to sneak bugs in.
What you do though is, you leave a very obscure edge case unhandled, make note of it, then just don't tell anyone. Invariably someone will hit it exactly one day before you're scheduled to go live. Then just apply the fix (make sure to procrastinate long enough to simulate working on it) and voila! The longest I've seen an edge case go unfixed in this manner has been three years.
Though truth be told I'm not smart enough to add bugs on purpose, I just sometimes notice I've failed to address an edge case and ... leave it. If it turns out to be important - I can fix it when the fix's value is maximum. Half my day is spent fixing others' unhandled edge cases, so it's nice to have one tucked away for a rainy day that you know you can fix easily.
How bizarre. I guess I can count myself lucky that I don't seem to live in that particular world.
Is the problem the incentive itself, eg. if they didn't reward fixed bugs would you write better (even just better communicated) code?
I can see how many would object to what you’re suggesting.
However, I’ve also had managers who pushed back against nice-to-have cleanups as the product matured (especially close to a release). They had cause as the product became overly complex, where issues were tedious to root cause and fix.
I tended to queue up a lot of improvements and then unleash them at the beginning of a release cycle.
Later QA would find a problem in the previous release but couldn’t reproduce in the later one… because I had already fixed it.
I didn’t introduce bugs intentionally, and the fixes were visible as we had to backport them for point releases, etc.