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."
Except that "time to fix" isn't the only factor that contributes to cost once a bug makes it into production.
There's damages caused by the bug, possible downtime due to deployment, testing and possibly certification, a potential need for data migration including dry-runs and more. These are just direct costs, too, there's also potential damage to reputation, cancelled orders, etc.
It shouldn't really surprise anyone that it doesn't really matter when you fix the bug in terms of effort required to just fix the bug itself. It's the process involved in communicating, planning and performing the rollout of fix that might sting real hard.
What's the cost of testing/specifying/formal methods/etc to a level that catches a bug before production vs what's the cost to fix a bug and its downstream effects.
If I work in an unregulated environment with on-demand deployment, the cost to fix a bug isn't that big, except for bugs that persist bad state/data and especially things involved with schema changes; those changes that are costly to fix necessitate costly testing. If I produce a game rom for unconnected systemsin million+ unit batches which sit on shelves for unknown time for people to use, it would be very costly to fix bugs and a costly test procedure for the whole thing makes sense.
If it's life safety, then yeah, lots of testing (and don't hire me)
All of that is true. Also, deployment from the cited date range of 1967 to 1981 didn't mean the same for a lot of software as it does today. For an integrated mainframe and minicomputer hardware and software business with a bunch of isolated customer sites and huge support contracts, we're talking customer outreach and physical media at the barest minimum. There's no "push to production" automated pipeline that publishes to a web server or package update that gets picked up from the repo by the next system cron at the customer's site over a fiber connection.
> 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