HackerPapers

arXiv:1609.04886cs.SE

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

Tim Menzies, William Nichols, Forrest Shull, Lucas Layman

Abstract

Many practitioners and academics believe in a delayed issue effect (DIE); i.e. the longer an issue lingers in the system, the more effort it requires to resolve. This belief is often used to justify major investments in new development processes that promise to retire more issues sooner. This paper tests for the delayed issue effect in 171 software projects conducted around the world in the period from 2006--2014. To the best of our knowledge, this is the largest study yet published on this effect. We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction. This paper documents the above study and explores reasons for this mismatch between this common rule of thumb and empirical data. In summary, DIE is not some constant across all projects. Rather, DIE might be an historical relic that occurs intermittently only in certain kinds of projects. This is a significant result since it predicts that new development processes that promise to faster retire more issues will not have a guaranteed return on investment (depending on the context where applied), and that a long-held truth in software engineering should not be considered a global truism.

arXiv comments
31 pages. Accepted with minor revisions to Journal of Empirical Software Engineering. Keywords: software economics, phase delay, cost to fix
Journal reference
Empirical Software Engineering, Volume 22, Issue 4, 1903--1935 (2017)
DOI
doi:10.1007/s10664-016-9469-x
Subjects
cs.SESoftware Engineering

On Hacker News

Linked by 4 identifiable commenters in 4 comments across 3 threads, from Sep 2017 to Feb 2025. Found in 2 HN submissions from Sep 2017 to Apr 2019. Open submission discussions.

Comments linking this paper, per year.

Discussed in comments3 threads

    • 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…

      kragenView on HNParent context

    • 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…

      jbellisView on HNParent context

    • 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…

      fulafelView on HNParent context

    • 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…

      MorendilView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.