I would be interested in hearing HN's take on the matter.
I'd imagine the tolerance for bugs in a support application written by IT is higher than the tolerance for bugs in a mission critical defense application. (Not to belittle a support application, in large organizations business logic can be exceedingly, unnecessarily complicated)
Overall, what would an acceptable, practical defect rate in IT?
It would be nice if these metrics ever actually helped, but mostly, they seem detached from reality. This article says that McCabe (cyclomatic) complexity "strongly correlates with program size or LOC". It's like nobody actually tried using the metrics.
It would be even better if somebody could define "quality", for software, or indeed, for anything else. There's inherent tension between "defect free" and "getting the project done", so you can't meet all definitions of "quality", if it's ever defined. Bellcore (became Telcordia, don't know what they are now) used to sell something called "QMO", but never actually defined "quality" other than mindlessly following the QMO specified behaviors.
2 comments
[ 4.8 ms ] story [ 13.0 ms ] threadI'd imagine the tolerance for bugs in a support application written by IT is higher than the tolerance for bugs in a mission critical defense application. (Not to belittle a support application, in large organizations business logic can be exceedingly, unnecessarily complicated)
Overall, what would an acceptable, practical defect rate in IT?
It would be even better if somebody could define "quality", for software, or indeed, for anything else. There's inherent tension between "defect free" and "getting the project done", so you can't meet all definitions of "quality", if it's ever defined. Bellcore (became Telcordia, don't know what they are now) used to sell something called "QMO", but never actually defined "quality" other than mindlessly following the QMO specified behaviors.