"How much time does your employer allow you to spend on solving one bug?"
It's hard to answer that question because bugs exhibit so much variation across many variables:
- Some bugs take minutes to fix (e.g., an obvious typo or omission in the code) but others may take weeks to fix (e.g., the programmer misunderstood the requirements and has to rework a large part of the code to fix erroneous assumptions; or a bug occurs intermittently under conditions that nobody has yet figured out how to reliably reproduce).
- Some kinds of code may be harder to debug, e.g., a web app is usually easier to debug than a device driver, since there's more visibility into what the code is doing.
- Some bugs are of critical importance to key customers (and thus justify a big time investment), but some are in obscure parts of the product that nobody uses (and may not be worth fixing at all).
- Some bugs make it impossible to use an important feature (justifying a big time investment), but others can be easily worked around.
- Some languages have constructs that make code harder to debug. E.g., there are lots of bugs that arise from memory management in C (using stale pointers to heap memory, etc.) that can never occur in higher-level languages.
- It's much easier to fix bugs in code that you wrote than in code written by someone else (who may have left the company and is not available to answer questions).
A major performance and cache corruption bug in production had four people (on a 6 person team) each spending probably 12 hours per week on it for two months.
A complex corner case that gets hit twice per week out of 100 million requests has been ignored for two years.
A bug that only affected bad actors (people hitting a spam detection threshold, even in good faith, were getting 500 errors instead of a warning) waited a week even though it was just an obvious one-line fix.
The thing about bugs is that you often don't know what's causing them, and some are too complex or require too-specific conditions to be able to track down. If you don't know what's causing it, there's no way to know how difficult it will be to fix.
So most bugs get - if not timeboxed - heavy follow up and pressure to fix it or drop it or work around it after a couple days of non-progress. But there are some bugs you just have to keep working on until you squash them, no matter how long that takes.
2 comments
[ 4.8 ms ] story [ 17.8 ms ] threadIt's hard to answer that question because bugs exhibit so much variation across many variables:
- Some bugs take minutes to fix (e.g., an obvious typo or omission in the code) but others may take weeks to fix (e.g., the programmer misunderstood the requirements and has to rework a large part of the code to fix erroneous assumptions; or a bug occurs intermittently under conditions that nobody has yet figured out how to reliably reproduce).
- Some kinds of code may be harder to debug, e.g., a web app is usually easier to debug than a device driver, since there's more visibility into what the code is doing.
- Some bugs are of critical importance to key customers (and thus justify a big time investment), but some are in obscure parts of the product that nobody uses (and may not be worth fixing at all).
- Some bugs make it impossible to use an important feature (justifying a big time investment), but others can be easily worked around.
- Some languages have constructs that make code harder to debug. E.g., there are lots of bugs that arise from memory management in C (using stale pointers to heap memory, etc.) that can never occur in higher-level languages.
- It's much easier to fix bugs in code that you wrote than in code written by someone else (who may have left the company and is not available to answer questions).
A major performance and cache corruption bug in production had four people (on a 6 person team) each spending probably 12 hours per week on it for two months.
A complex corner case that gets hit twice per week out of 100 million requests has been ignored for two years.
A bug that only affected bad actors (people hitting a spam detection threshold, even in good faith, were getting 500 errors instead of a warning) waited a week even though it was just an obvious one-line fix.
The thing about bugs is that you often don't know what's causing them, and some are too complex or require too-specific conditions to be able to track down. If you don't know what's causing it, there's no way to know how difficult it will be to fix.
So most bugs get - if not timeboxed - heavy follow up and pressure to fix it or drop it or work around it after a couple days of non-progress. But there are some bugs you just have to keep working on until you squash them, no matter how long that takes.