Re: I Can Hardly Wait for Self Driving Cars
"Testing shows the presence, not the absence of bugs"
Obvious to the meanest first-semester intelligence. The more so as bugs may be in the eyes of the beholder. Dijkstra's provable microproblems continue to make one think, but they are still irrelevant to real-world software (plus they were written in imperative style, which is hard to think about and hard to apply first-order logic on, in order words, inappropriate -- I hope Dijkstra-inspired curriculae have been reworked, mine was rather horrid btw. but it was probably also meant to weed out freshmen easily disgusted by mysterious symbology)
More interesting, in (paywalled):
Steve Tockey, "Insanity, Hiring, and the Software Industry", Computer, vol.48, no. 11, pp. 96-101, Nov. 2015
"Software project and product outcomes strongly suggest that the software industry still suffers from dismal performance. A brief survey of job postings reveals a significant gap between what hiring managers of software developer positions are asking for and what they actually need" (i..e NOT people "skilled in C++" but in actual system engineering and economic thinking)
we read:
The next question we should ask is, “What drives poor software project and product performance?” I’ve identified four major causes of poor performance, listed here in decreasing order of significance:
1) Vague, ambiguous and incomplete requirements
2) Inadequate project management
3) Overdependence on testing: It’s impossible to comprehensively test nontrivial code. .... Typical software testing teams are between 60 and 70 percent effective at finding defects, meaning users discover 30 to 40 percent of software defects. The cost to repair any defect increases exponentially as the project progresses—that is, fixing a defective requirement after code has been written is many times more expensive than fixing that same requirement defect before design and coding work has begun. Return on investment for software inspections—a form of peer review—has been reported as high as 44:1. Thus, each person-hour spent inspecting requirements and design avoided as many as 44 person-hours of rework later in the project
4) Uncontrolled code complexity
.
But that's just by the by
Biting the hand that feeds IT
