The time and cost to fix bugs can have a huge variance which is sometimes dependent on the nature and field of the software being written. There are bugs that take seconds to fix and others that take months.
I have personally experienced hunting down a bug for six months nearly full time (10 to 12 hours per day) until it was finally found. This was a real-time hardware system and the code was that of an FPGA. The culprit was a coefficient in one of many polyphase finite impulse response filters. The calculations used to generate this coefficient were done in a huge Excel spreadsheet. At one point, in the hundreds of equations in the spreadsheet, the author had used the ROUND() function when the ROUNDUP() function should have been used. This was enough cause a buffer issue in the FIFO feeding the polyphase filter. These are tricky problems to track down when you are literally looking for events that take somewhere in the order of single-digit nanoseconds to occur.
On the other hand, there are those bugs where you know exactly what is going on and where in the code it is happening the instant you see the behavior. We've all experienced that during the course of software development.
Fixing bugs for a dating website has vastly different requirements than, say, fixing bugs in a flight control system.
One argument is for more up-front planning in order to avoid some bugs. At one point this can quickly become counterproductive. Sometimes it's better to just start writing code and fix issues as they come up.
Now, if we are talking about fixing bugs after the fact, that's a different matter. One example here might be if you inherit the code to a complex website or an engine control system and, without any familiarity with the code, are required to fix bugs. This can easily take cubic time as it requires to learn the code-base (and sometimes the subject matter) while also trying to hunt down bugs.
This is why I tend to take such tables or studies with great skepticism. I haven't really paid much attention to these studies, but I remember looking at one or two of them and thinking that they tended to focus on narrow cases such as fixing bugs in-house, with a stable programmer team and great familiarity with the code base.
Skepticism is deserved. It's a very fine balance, and bearing in mind not much software exist that is entirely bug-free.
What is the cost of a bug that is never discovered? Is it negative?
What is the cost of fixing a bug that would never have caused a problem (at each stage of development)?
I have personally experienced hunting down a bug for six months nearly full time (10 to 12 hours per day) until it was finally found. This was a real-time hardware system and the code was that of an FPGA. The culprit was a coefficient in one of many polyphase finite impulse response filters. The calculations used to generate this coefficient were done in a huge Excel spreadsheet. At one point, in the hundreds of equations in the spreadsheet, the author had used the ROUND() function when the ROUNDUP() function should have been used. This was enough cause a buffer issue in the FIFO feeding the polyphase filter. These are tricky problems to track down when you are literally looking for events that take somewhere in the order of single-digit nanoseconds to occur.
On the other hand, there are those bugs where you know exactly what is going on and where in the code it is happening the instant you see the behavior. We've all experienced that during the course of software development.
Fixing bugs for a dating website has vastly different requirements than, say, fixing bugs in a flight control system.
One argument is for more up-front planning in order to avoid some bugs. At one point this can quickly become counterproductive. Sometimes it's better to just start writing code and fix issues as they come up.
Now, if we are talking about fixing bugs after the fact, that's a different matter. One example here might be if you inherit the code to a complex website or an engine control system and, without any familiarity with the code, are required to fix bugs. This can easily take cubic time as it requires to learn the code-base (and sometimes the subject matter) while also trying to hunt down bugs.
This is why I tend to take such tables or studies with great skepticism. I haven't really paid much attention to these studies, but I remember looking at one or two of them and thinking that they tended to focus on narrow cases such as fixing bugs in-house, with a stable programmer team and great familiarity with the code base.