Hopefully this will end in a discussion in which the actual data underlying the table can be had and matched up.
Anecdotally, it seems to make sense that it is more expensive to find and fix a defect later in the process. If a dev finds a defect while implementing a feature, only his costs are involved. However, if a defect is found later in the our process, at least 2 qa analysts are involved: one to find the defect and another to confirm it. After that a project manager schedules out time and assigns the defect out to a developer, possibly not the one that introduced the defect gets the assignment to fix it. The developer fixes the defect, a build is made by the build person. The original tester retests the defect and marks the fix as being verified.
That seems complex, but there are possibly even more steps than that. Unit tests may need to be written, customer test cases may need to be updated.
I don't know if the costs end up being exponentially greater, but they would seem to be greater.
At any rate, it would be good to have someone independently validate that data.
It's not written in stone that you need 2 QA analysts, a project manager, a developer, and a build master to fix a bug. That only proves that bureaucracy is expensive, not that fixing bugs "late" in the process is expensive!
I'm not sure what exactly the second QA person adds to the process. As a developer, I need to be able to reproduce a bug myself in order to have any chance of fixing it, so there's your confirmation step right there.
Project manager? No, just have your QA person file the ticket as a bug (with the correct priority) and have your developers pull tickets off your bug tracker themselves. At worst, a slight email/verbal nudge from the usual boss should do.
Build person? No, have a continuous, automated build system. The job of the build person should be to maintain that system, not to run individual builds.
Now you're down to one QA person to file the ticket, one developer to fix the bug, and the same QA person again to close the ticket. Add in a few minutes of another developer's time to code review the first developer (you don't even do that despite having all that process?) and it's still cheaper.
Unit tests? Developers write their own unit tests. Have a failing unit test that reproduces the root cause of the bug before you fix the bug--that's a best practice anyway. For testing above and beyond that, it's not unreasonable to have SDETs maintain that stuff, though you already have the root cause of the bug captured in a unit test so your main concern should be whether any existing tests actually rely upon the broken behavior.
It's not written in stone that you need 2 QA analysts, a project manager, a developer, and a build master to fix a bug.
Well - that depends. For plenty of large software engineering projects (think aerospace) it's a given that you'll have that organization many times over.
On the other hand, a web startup may produce a high-quality shipping product with just two or three devops. The number of "lines of code" may even end up being similar between the two deliverables.
The code that gets burned into an ASIC requires a completely different set of development considerations than a non-critical "make deploy_production" web service.
But how do you quantify all these confounding factors?
Right - the aerospace people aren't stupid - far from it. They simply have vastly different goals and constraints, and thus a different organization and a different development process.
And don't forget that you'd have other costs involved:
o The cost to fix the corrupted data
o Opportunity costs of a broken software (it is Black Friday and your site is down)
o Image costs of the ability of your company/product
o The costumer cost (specially if she is also from your company)
These costs are very difficult to measure. The chart is popular because it matches our expectation as developers.
Anecdotally, it seems to make sense that it is more expensive to find and fix a defect later in the process. If a dev finds a defect while implementing a feature, only his costs are involved. However, if a defect is found later in the our process, at least 2 qa analysts are involved: one to find the defect and another to confirm it. After that a project manager schedules out time and assigns the defect out to a developer, possibly not the one that introduced the defect gets the assignment to fix it. The developer fixes the defect, a build is made by the build person. The original tester retests the defect and marks the fix as being verified.
That seems complex, but there are possibly even more steps than that. Unit tests may need to be written, customer test cases may need to be updated.
I don't know if the costs end up being exponentially greater, but they would seem to be greater.
At any rate, it would be good to have someone independently validate that data.