3 ms·

I am not sure if you can answer the question. It depends on the bug of course. If data sets of a production system are affected, it can indeed mean a lot of wor

I am not sure if you can answer the question. It depends on the bug of course. If data sets of a production system are affected, it can indeed mean a lot of work For some other bugs there might not be a difference. There cannot be a general answer to this question, there are too many factors involved. Modern development makes some things easier than it was in the past. Then again there will also be new problems.

krisoft 5y ago
It is also very field dependent. I worked on a web project where we could deploy with a line of command. Also worked on a project where "testing the new version for real" meant that we had to charter an airplane, hire a pilot, drive to the airport, strap things to the aircraft, calibrate the system and then get airborne. Understandably this changes the cost of errors, and thus people's attitude to quality.
db48x 5y ago
Of course we could answer the question if we really wanted to. It’s not actually very hard to count the time spent on a bug and then multiply that by the salaries of the people involved.
- incrudible 5y ago
  This is an oversimplification of the problem. Nobody is interested in the cost of "a bug", but their set of bugs. The cost is not just salary, it's also "missed sales". It may be the one bug, otherwise harmless, that shifts the opinion of a major decision maker. It may be the bug that causes some amount of users to finally look elsewhere, already being frustrated from previous bugs. It may be the bug that triggers a disgruntled user to write a rant on your product that ends up as a top google search result.
  - db48x 5y ago
    Direct costs are all anyone means when they say that “bugs are 100× more expensive to fix in production”. There’s nothing in that statement about indirect or reputational costs, just the cost to fix. The factors you mention all exist, but they are irrelevant to the cost of fixing a bug. They are very relevant to the cost of _failing_ to fix a bug. What is relevant is your definition of the various stages of development. The numbers that are the source of the “100×” figure are from the development of an anti–ballistic missile system from the sixties or seventies. They would have been programming in assembler (thus the “27 lines of code patched per change” is not unusual). Finding and fixing a bug in the software after you’ve built all the missiles and shipped them to every ballistic missile base in the US could indeed be very expensive! But if your release process is just copying the new code to a server (or even a fleet of servers) and restarting some services, then it’s not expensive at all. Most of us have a very different idea of what “releasing” the software means than the folks on this project had. https://gist.github.com/Morendil/f9c2e9f3f450d3a76de8aeee7cf2bd00 https://gist.github.com/Morendil/f9c2e9f3f450d3a76de8aeee7cf...

krisoft 5y ago

It is also very field dependent. I worked on a web project where we could deploy with a line of command. Also worked on a project where "testing the new version for real" meant that we had to charter an airplane, hire a pilot, drive to the airport, strap things to the aircraft, calibrate the system and then get airborne. Understandably this changes the cost of errors, and thus people's attitude to quality.

db48x 5y ago

Of course we could answer the question if we really wanted to. It’s not actually very hard to count the time spent on a bug and then multiply that by the salaries of the people involved.

incrudible 5y ago
This is an oversimplification of the problem. Nobody is interested in the cost of "a bug", but their set of bugs. The cost is not just salary, it's also "missed sales". It may be the one bug, otherwise harmless, that shifts the opinion of a major decision maker. It may be the bug that causes some amount of users to finally look elsewhere, already being frustrated from previous bugs. It may be the bug that triggers a disgruntled user to write a rant on your product that ends up as a top google search result.
- db48x 5y ago
  Direct costs are all anyone means when they say that “bugs are 100× more expensive to fix in production”. There’s nothing in that statement about indirect or reputational costs, just the cost to fix. The factors you mention all exist, but they are irrelevant to the cost of fixing a bug. They are very relevant to the cost of _failing_ to fix a bug. What is relevant is your definition of the various stages of development. The numbers that are the source of the “100×” figure are from the development of an anti–ballistic missile system from the sixties or seventies. They would have been programming in assembler (thus the “27 lines of code patched per change” is not unusual). Finding and fixing a bug in the software after you’ve built all the missiles and shipped them to every ballistic missile base in the US could indeed be very expensive! But if your release process is just copying the new code to a server (or even a fleet of servers) and restarting some services, then it’s not expensive at all. Most of us have a very different idea of what “releasing” the software means than the folks on this project had. https://gist.github.com/Morendil/f9c2e9f3f450d3a76de8aeee7cf2bd00 https://gist.github.com/Morendil/f9c2e9f3f450d3a76de8aeee7cf...