Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle · HackerPapers discussions

Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle — mentioned by kragen

Tue, 25 Feb 2025 22:03:07 GMT

I read some of the more questionable parts of the second edition just now, and while I think there are a lot of things to criticize in it, I suspect that it's just rose-tinted hindsight, or ignorance, that made me not object to them in the first edition; I'm pretty sure most of these problems were already there: - All the time wasted on the dumb "construction" analogy. - The total lack of attention to open-source software, possibly because he was misled by his own "construction" analogy. There's no such thing as a freely redistributable cabinet that's extra reliable because your house shares…

Paper and discussion history. A mention is not an endorsement.

Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle — mentioned by jbellis

Thu, 22 Jul 2021 14:23:29 GMT

It's buried a bit, but it actually does kind of refute that. > Here is a 2016 paper [PDF] whose authors "examined 171 software projects conducted between 2006 and 2014," all of which used a methodology called the Team Software Process. The researchers concluded that "the times to resolve issues at different times were usually not significantly different." Link is to https://arxiv.org/pdf/1609.04886.pdf

Paper and discussion history. A mention is not an endorsement.

Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle — HN submission

Sat, 06 Apr 2019 16:42:25 GMT

Are Delayed Issues Harder to Resolve? [pdf]

2 points; 1 discussion reply on HN. Paper and source history. A submission is not an endorsement.

Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle — mentioned by Morendil

Mon, 11 Sep 2017 06:24:26 GMT

I'm a big fan of TDD, but I quit reading this article the second my eyes came across "IBM System Sciences Institute" and the chart that accompanies it. This is by now one of the most thoroughly debunked memes in our profession. I wrote a couple chapters about it: http://leanpub.com/leprechauns . I wrote a handy little guide for people to know just how much BS was involved in any one citation: https://plus.google.com/+LaurentBossavit/posts/aNKut1QV8pT If that wasn't enough, there is now an actual negative research result on the so-called defect cost increase…

Paper and discussion history. A mention is not an endorsement.

Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle — HN submission

Mon, 11 Sep 2017 05:40:39 GMT

Revisiting Cost-To-Fix of Defects Throughout the Lifecycle

3 points; 1 discussion reply on HN. Paper and source history. A submission is not an endorsement.

Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle — mentioned by fulafel

Mon, 11 Sep 2017 05:23:37 GMT

Googling more, the same vaguely sourced "IBM System Sciences" figure seems to be passed on from one poorly researched web post to another. The trail went cold but it seems to date back to the mainframe IBM of the 1970's or 1980's. Certainly it's from a different software engineering culture than today's continuous delivery processes. A promising looking current review of the question is here: https://link.springer.com/article/10.1007/s10664-016-9469-x (PDF link: https://arxiv.org/pdf/1609.04886.pdf) They conclude: "We checked for traces of this effect in 171 projects from the period…

Paper and discussion history. A mention is not an endorsement.