Engineering and Software Engineering (2010) [pdf] | Hacker News Reader

Engineering and Software Engineering (2010) [pdf]

mcs.open.ac.uk

63 pointstmcb13 comments

It is worth noting that the cost of correcting inaccurate software has gone down.

Looking at the decision to adopt some defect prevention strategy in software. Cost of strategy < ∑(perceived chance of a defect being prevented)*(cost of the defect + cost of correcting the defect)

1968 vs 2018 Cost of strategy I doubt this changed much. For some strategies, this changed a lot, like Buy vs Build where the cost to buy has gone to near zero due to npm, NuGet, CPAN etc.

Cost of the defect I doubt the perception of this changed much, whether that is accurate is up for debate. Software defects are prone to long tail events that will have a disproportionate effect.

Cost of correcting the defect This went to engineers send on a plane with physical media to some customers mainframe to floppies in the mail to downloadable patch installers to asking the customer to patch from the application to pushing code and letting automated build, deploy, test and background updates. Compared to 1968 the cost went almost to zero.

Strategies have to be better or cheaper to be adopted vs 1968; because the costs of defects have plummeted for many organizations. Unfortunately, the author only references "cost" once in the 15 pages.

This is true although the number of users has increased since 1968, a defect at Google or Facebook is going to affect millions.

Sort of, they actually do rolling updates so that a new version of the code does not affect the whole user base at once. So again, reducing the cost of incorrect software. But it does happen, the VW emission scandal was effectively incorrect code. Noone predicted the 22 billion dollar defect, but due to re-use of components, it is possible.

Long Tail events is a big problem in software and a few lines of code are responsible for a large part of the costs (for a longer version of this answer https://possumlabs.com/the-cost-of-software-bugs-5-powerful-...).

"But it does happen, the VW emission scandal was effectively incorrect code."

I don't think we should call what VW did "incorrect software". It actually did what it was supposed to do.

This is a valid observation; however, we also need to consider that we write orders of magnitude more software in 2018 than we did in 1968. I don't think the defect / LOC (or whatever metric you want to use) has decreased. So while the cost per defect might be far lower, the total number of defects keeps increasing. The mitigation strategies that I've seen reduce costs mainly because they simply choose not to fix a lot of problems.

I prefer to look at value and costs.

To me LoC is an indicator of how much you'll spend on maintenance; less is better.

I think that defects per unit of value have plummeted.

The topic is fascinating, but I found this paper hard to read.

Could someone provide an extra clear ELI5 so I can re-read with that context in mind?

Is the author the Michael Jackson of Jackson Structured Programming fame?

I believe so; the author affiliation is the same as that Michael Jackson, and the paper references an earlier paper by that Michael Jackson.

http://mcs.open.ac.uk/mj665/

I didn't expect the paper to be a thriller!

This author won't stop 'til he gets enough.

Yes, but at least he wanna get started something

Reply on news.ycombinator.com