4 ms·

I'm disappointed to see a book aimed at "professional" developers continue to spread outdated and debunked information, such as the NIST "study" adduced as evid

I'm disappointed to see a book aimed at "professional" developers continue to spread outdated and debunked information, such as the NIST "study" adduced as evidence for the imperative necessity of "defect cost containment". See my post on the topic: https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ Or again the Wikipedia page on the history of software engineering, which is frightfully inadequate. https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK I'll add my voice to those that have already stated such a book shouldn't start by assuming the SDLC as a reference model: it embodies too many of those outdated assumptions. More in that vein in my own book http://leanpub.com/leprechauns http://leanpub.com/leprechauns

agentultra 10y ago
I haven't read all of it yet but it also seems to miss the vein of development that has led to movements such as Correct by Construction et al. The idea that we should model our computations in a high-level specification and check that those designs meet our goals and hold the invariants we press upon them. Instead there's Agile and the idea that we can throw together something that roughly works and iterate until our confidence is enough such that we can release it. The so-called, beta-driven-development. (Perhaps a vestigial remnant of the unix philosophy?). I'm not arguing that formal methods should be used for every software project. I think Carmack was right to point out that if all software was written like the software at JPL we'd be decades behind where we are now. However I do think that it should be a part of the experience of becoming a programmer so that when we encounter hard problems we have the correct instincts to rely on mathematics to help us.
- mixmastamyk 10y ago
  This is a beginners book, and keeping in mind we can't teach them everything in the first "semester," do you still think this topic should be included?
  - agentultra 10y ago
    Definitely think the groundwork can be laid out without covering the entire breadth of formal methods. Even a history lesson with Djiskstra, Lamport, Mizra, et al can be illuminating. It's good to lay the foundation so that when a beginner encounters a problem they have the instincts to know that they should look up these tools in order to help them. I found it a shame that I didn't encounter these tools only until very recently. It's a well kept secret in academia that I think should be shared.
mixmastamyk 10y ago
The NIST study graphic matched another from the book Code Complete, to illustrate the cost of defects. I did not have access to the CC graph so I used it instead. Do you believe the larger point (about cost of defects) is incorrect? Your g+ critique seems to take issue with the details of the study, but I missed an assertion it is wrong. As to the wikipedia timeline, I cherry picked from it. The point being to pick the important things a student should know, not list everything possible. Seems your WP edits didn't make it through?
- Morendil 10y ago
  I'd put the cost of defects claim in the category "not even wrong". If someone made quantified claims about "the number of minutes of life lost to smoking one cigarette" I would refuse to take them seriously: I would argue that the health risk from smoking is more complex than that and can't be reduced to such a linear calculation. This talk about "the cost of a defect" has the same characteristics. I don't mean the above argument by analogy to be convincing in and of itself, and I've written more extensively about my thinking e.g. here: https://plus.google.com/u/1/+LaurentBossavit/posts/8tB2RQoHQLF https://plus.google.com/u/1/+LaurentBossavit/posts/8tB2RQoHQ... But it's a large topic that quite possibly deserve a book of its own. As for the history of software engineering, it's pretty much the same - to do it properly would entail writing a book, pretty much, and I didn't want to do it on WP unless I could do it properly.
  - mixmastamyk 10y ago
    Table and Figure 3.1 in Code Complete support the conclusion and is well cited: Source: Adapted from “Design and Code Inspections to Reduce Errors in Program Development” (Fagan 1976), Software Defect Removal (Dunn 1984), “Software Process Improvement at Hughes Aircraft” (Humphrey, Snyder, and Willis 1991), “Calculating the Return on Investment from More Effective Requirements Management” (Leffingwell 1997), “Hughes Aircraft’s Widespread Deployment of a Continuously Improving Software Process” (Willis et al. 1998), “An Economic Release Decision Model: Insights into Software Project Management” (Grady 1999), “What We Have Learned About Fighting Defects” (Shull et al. 2002), and Balancing Agility and Discipline: A Guide for the Perplexed (Boehm and Turner 2004). Joel on Software also has a convincing narrative on the subject. Therefore I'm not in a big hurry to replace the image, though I will put it on my todo-list.

agentultra 10y ago

I haven't read all of it yet but it also seems to miss the vein of development that has led to movements such as Correct by Construction et al. The idea that we should model our computations in a high-level specification and check that those designs meet our goals and hold the invariants we press upon them. Instead there's Agile and the idea that we can throw together something that roughly works and iterate until our confidence is enough such that we can release it. The so-called, beta-driven-development. (Perhaps a vestigial remnant of the unix philosophy?). I'm not arguing that formal methods should be used for every software project. I think Carmack was right to point out that if all software was written like the software at JPL we'd be decades behind where we are now. However I do think that it should be a part of the experience of becoming a programmer so that when we encounter hard problems we have the correct instincts to rely on mathematics to help us.

mixmastamyk 10y ago
This is a beginners book, and keeping in mind we can't teach them everything in the first "semester," do you still think this topic should be included?
- agentultra 10y ago
  Definitely think the groundwork can be laid out without covering the entire breadth of formal methods. Even a history lesson with Djiskstra, Lamport, Mizra, et al can be illuminating. It's good to lay the foundation so that when a beginner encounters a problem they have the instincts to know that they should look up these tools in order to help them. I found it a shame that I didn't encounter these tools only until very recently. It's a well kept secret in academia that I think should be shared.

mixmastamyk 10y ago

The NIST study graphic matched another from the book Code Complete, to illustrate the cost of defects. I did not have access to the CC graph so I used it instead. Do you believe the larger point (about cost of defects) is incorrect? Your g+ critique seems to take issue with the details of the study, but I missed an assertion it is wrong. As to the wikipedia timeline, I cherry picked from it. The point being to pick the important things a student should know, not list everything possible. Seems your WP edits didn't make it through?

Morendil 10y ago
I'd put the cost of defects claim in the category "not even wrong". If someone made quantified claims about "the number of minutes of life lost to smoking one cigarette" I would refuse to take them seriously: I would argue that the health risk from smoking is more complex than that and can't be reduced to such a linear calculation. This talk about "the cost of a defect" has the same characteristics. I don't mean the above argument by analogy to be convincing in and of itself, and I've written more extensively about my thinking e.g. here: https://plus.google.com/u/1/+LaurentBossavit/posts/8tB2RQoHQLF https://plus.google.com/u/1/+LaurentBossavit/posts/8tB2RQoHQ... But it's a large topic that quite possibly deserve a book of its own. As for the history of software engineering, it's pretty much the same - to do it properly would entail writing a book, pretty much, and I didn't want to do it on WP unless I could do it properly.
- mixmastamyk 10y ago
  Table and Figure 3.1 in Code Complete support the conclusion and is well cited: Source: Adapted from “Design and Code Inspections to Reduce Errors in Program Development” (Fagan 1976), Software Defect Removal (Dunn 1984), “Software Process Improvement at Hughes Aircraft” (Humphrey, Snyder, and Willis 1991), “Calculating the Return on Investment from More Effective Requirements Management” (Leffingwell 1997), “Hughes Aircraft’s Widespread Deployment of a Continuously Improving Software Process” (Willis et al. 1998), “An Economic Release Decision Model: Insights into Software Project Management” (Grady 1999), “What We Have Learned About Fighting Defects” (Shull et al. 2002), and Balancing Agility and Discipline: A Guide for the Perplexed (Boehm and Turner 2004). Joel on Software also has a convincing narrative on the subject. Therefore I'm not in a big hurry to replace the image, though I will put it on my todo-list.