3 ms·

Unfortunately there seems to be no reference to the study and how it got to its conclusion. I know in the embedded world, that factor can be a lot higher, in

Unfortunately there seems to be no reference to the study and how it got to its conclusion. I know in the embedded world, that factor can be a lot higher, in the web world, it can be a lot lower. Also this article multiplies a number of stats together, but It doesn't look to me that the stats referenced are super solid. In fact it seems the stats are all over the place trying to measure the benefit of TDD and live in the realm of "That's really interesting, further research needed"

fulafel 9y ago
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 https://link.springer.com/article/10.1007/s10664-016-9469-x (PDF link: https://arxiv.org/pdf/1609.04886.pdf https://arxiv.org/pdf/1609.04886.pdf) They conclude: "We checked for traces of this effect in 171 projects from the period 2006–2014. That data held no trace of the delayed issue effect. To the best of our knowledge, this paper is the largest study of this effect yet performed." ... "Our results beg the question: why does the delayed issue effect persist as a truism in software engineering literature? No doubt the original evidence was compelling at the time, but much has changed in the realm of software development in the subsequent 40 years."