The "28x productivity" (or 10x or Xx ...) claim always triggers warning bells for me. http://morendil.github.io/folklore.html does a pretty good job explaining how the research backing that widely accepted "fact" may be questionable.
I also really like Dan Luu's review of the research behind static typing at http://danluu.com/empirical-pl/ as an example of how a "well studied" claim can still be questionable due to the massive difficulty in evaluating software engineering empirically.
Software engineering is a very human activity and that makes it very hard to measure and quantify.
A book that does a better job is Making Software (http://www.amazon.com/Making-Software-ebook/dp/B004D4YI6G/re...) but as my first link points out, it still has some issues. At least its goal is to get more rigorous in our scientific analysis of software engineering."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Frequently Forgotten Fundamental Facts about Software Engineering (2001) [pdf]"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"http://www.kictanet.or.ke/wp-content/uploads/2012/08/Forgotten-Fundamentals-IEEE-Software-May2001.pdf"}},"_tags":["comment","author_bhntr3","story_9450873"],"author":"bhntr3","children":[9455159],"comment_text":"The lack of citations is concerning. I could read his book but it worries me when numbers like these are thrown around without some way to verify the analysis.
The "28x productivity" (or 10x or Xx ...) claim always triggers warning bells for me. http://morendil.github.io/folklore.html does a pretty good job explaining how the research backing that widely accepted "fact" may be questionable.
I also really like Dan Luu's review of the research behind static typing at http://danluu.com/empirical-pl/ as an example of how a "well studied" claim can still be questionable due to the massive difficulty in evaluating software engineering empirically.
Software engineering is a very human activity and that makes it very hard to measure and quantify.
A book that does a better job is Making Software (http://www.amazon.com/Making-Software-ebook/dp/B004D4YI6G/re...) but as my first link points out, it still has some issues. At least its goal is to get more rigorous in our scientific analysis of software engineering.","created_at":"2015-04-28T17:52:19Z","created_at_i":1430243539,"objectID":"9454069","parent_id":9453304,"points":null,"story_id":9450873,"story_title":"Frequently Forgotten Fundamental Facts about Software Engineering (2001) [pdf]","story_url":"http://www.kictanet.or.ke/wp-content/uploads/2012/08/Forgotten-Fundamentals-IEEE-Software-May2001.pdf","updated_at":"2023-09-07T02:37:31Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"ExpiredLink"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"> Fact and folklore in software engineering
http://morendil.github.io/folklore.html
> 10x Engineer
http://web.archive.org/web/20131110050028/https://medium.com..."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"The Programmer's Price: Want to hire a coding superstar? Call the agent"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"http://www.newyorker.com/magazine/2014/11/24/programmers-price"}},"_tags":["comment","author_ExpiredLink","story_8616952"],"author":"ExpiredLink","comment_text":"> Fact and folklore in software engineering
http://morendil.github.io/folklore.html
> 10x Engineer
http://web.archive.org/web/20131110050028/https://medium.com...","created_at":"2014-11-17T15:34:29Z","created_at_i":1416238469,"objectID":"8618605","parent_id":8617902,"story_id":8616952,"story_title":"The Programmer's Price: Want to hire a coding superstar? Call the agent","story_url":"http://www.newyorker.com/magazine/2014/11/24/programmers-price","updated_at":"2024-09-19T21:15:41Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"jdlshore"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"I've been a fan of Laurent's work in this area for a long time.
What I find most interesting is that Laurent's work is clearly about the pervasiveness of myth and the need to apply rigorous thinking to what we believe. It's not about the specific claims; those are (fascinating) examples.
And yet, every time, people get really worked up about the 10x issue. They ignore the broader point entirely and focus on that one claim. (I find it particularly interesting that they focus on 10x and not any of the other claims Laurent debunks. Perhaps because it's easily understood? Perhaps because it's easy to think of anecdotes? Perhaps\u2014and I suspect this is the real truth\u2014because they secretly believe in their hearts that they're among the Chosen, and Laurent's threatening their clubhouse?)
Laurent doesn't say, "there are no 10x programmers." He says, "the studies that claim 10x programmers are so weak as to be laughable, the notion of measuring productivity itself is controversial and poorly defined, and do you even know which ratio you're using when you say 10x, anyway?" (He's not quite so informal about it, but that's the gist.)
In other words, the 10x claim has yet to be defined, let alone subject to rigorous analysis.
But out of the woodwork come these people who say, "I've seen 10x, therefore it must be true!" (I can't help but believe that these are the same people who jump up and down saying "the plural of anecdote is not data.") To be blunt: irrelevant. Laurent didn't say "there are no 10x programmers." Sit down already. Read it again.
You know what? The 10x claim doesn't matter. Laurent's not even saying it matters. His argument is bigger, more interesting, and more valuable than that.
He's saying that people\u2014us programmers, specifically, who so wish ourselves to be rational thinkers\u2014believe things because we want them to be true. Not because of the "evidence" and "proof" we're so keen to demand when we hear something we don't like... but because they're the myths that surround us, and they make us feel good.
(And now I hope morendil will chime in and tell me how I've misinterpreted him. ;-) )"},"story_title":{"matchLevel":"none","matchedWords":[],"value":"The Making of Software Engineering Myths"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"http://modelviewculture.com/pieces/the-making-of-myths"}},"_tags":["comment","author_jdlshore","story_7417063"],"author":"jdlshore","children":[7419064,7419396],"comment_text":"I've been a fan of Laurent's work in this area for a long time.
What I find most interesting is that Laurent's work is clearly about the pervasiveness of myth and the need to apply rigorous thinking to what we believe. It's not about the specific claims; those are (fascinating) examples.
And yet, every time, people get really worked up about the 10x issue. They ignore the broader point entirely and focus on that one claim. (I find it particularly interesting that they focus on 10x and not any of the other claims Laurent debunks. Perhaps because it's easily understood? Perhaps because it's easy to think of anecdotes? Perhaps\u2014and I suspect this is the real truth\u2014because they secretly believe in their hearts that they're among the Chosen, and Laurent's threatening their clubhouse?)
Laurent doesn't say, "there are no 10x programmers." He says, "the studies that claim 10x programmers are so weak as to be laughable, the notion of measuring productivity itself is controversial and poorly defined, and do you even know which ratio you're using when you say 10x, anyway?" (He's not quite so informal about it, but that's the gist.)
In other words, the 10x claim has yet to be defined, let alone subject to rigorous analysis.
But out of the woodwork come these people who say, "I've seen 10x, therefore it must be true!" (I can't help but believe that these are the same people who jump up and down saying "the plural of anecdote is not data.") To be blunt: irrelevant. Laurent didn't say "there are no 10x programmers." Sit down already. Read it again.
You know what? The 10x claim doesn't matter. Laurent's not even saying it matters. His argument is bigger, more interesting, and more valuable than that.
He's saying that people\u2014us programmers, specifically, who so wish ourselves to be rational thinkers\u2014believe things because we want them to be true. Not because of the "evidence" and "proof" we're so keen to demand when we hear something we don't like... but because they're the myths that surround us, and they make us feel good.
(And now I hope morendil will chime in and tell me how I've misinterpreted him. ;-) )","created_at":"2014-03-17T23:01:41Z","created_at_i":1395097301,"objectID":"7418709","parent_id":7417063,"story_id":7417063,"story_title":"The Making of Software Engineering Myths","story_url":"http://modelviewculture.com/pieces/the-making-of-myths","updated_at":"2024-09-19T20:32:15Z"},{"_highlightResult":{"author":{"fullyHighlighted":true,"matchLevel":"full","matchedWords":["mirendil"],"value":"Morendil"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"Sure, you can grab my Agile bib file here: https://github.com/Morendil/referentiel.institut-agile.fr/bl...
There are 48 papers tagged with \"tdd\"."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"An apology to readers of Test-Driven iOS Development"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"http://blog.securemacprogramming.com/2012/09/an-apology-to-readers-of-test-driven-ios-development/"}},"_tags":["comment","author_Morendil","story_4474166"],"author":"Morendil","comment_text":"Sure, you can grab my Agile bib file here: https://github.com/Morendil/referentiel.institut-agile.fr/bl...
There are 48 papers tagged with \"tdd\".","created_at":"2012-09-04T18:34:12Z","created_at_i":1346783652,"objectID":"4475853","parent_id":4475777,"story_id":4474166,"story_title":"An apology to readers of Test-Driven iOS Development","story_url":"http://blog.securemacprogramming.com/2012/09/an-apology-to-readers-of-test-driven-ios-development/","updated_at":"2024-09-19T18:51:18Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"kragen"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"I read some of the more questionable parts of the second edition just now, and while I think there are a lot of things to criticize in it, I suspect that it's just rose-tinted hindsight, or ignorance, that made me not object to them in the first edition; I'm pretty sure most of these problems were already there:
- All the time wasted on the dumb "construction" analogy.
- The total lack of attention to open-source software, possibly because he was misled by his own "construction" analogy. There's no such thing as a freely redistributable cabinet that's extra reliable because your house shares it with the local nuclear reactor, or a rotten floor joist you can't fix without negotiating a source license. (He does discuss buying libraries, just as you can buy cabinets instead of building them.) Though this was surely also lacking in the first edition, it was a more forgivable oversight in 01994.
- Very little attention given to automated testing; we don't get to "developer testing" until chapter 22, and even that's mostly about manual testing, though there are a few offhand remarks in \u00a74.4 and \u00a79.4 about unit testing and test-first programming, with no explanation of what that means. Even when he tries to explain "test-first programming" in \u00a722.2, there's no hint that we're talking about automated testing. And we finally see mentions of "test code" and "JUnit" in \u00a722.4, and then \u00a722.5 and \u00a722.6 have information about actual automated testing, though without any actual test code. The advice on test-case design is still excellent.
- Also, very little about source control. I know this was a deficiency in the first edition because I remember the revelation of learning about RCS a couple of years after I read it. I think it actually got better in the second edition; there's a little "Version Control" section in \u00a730.2 which refers you to \u00a728.2, "Configuration Management", which talks a little bit about the problem but doesn't mention Subversion (first released October 02000), CVS (01990), RCS (01982), SCCS (01973), or even Visual SourceSafe (01994). Instead, it mostly describes implementing similar processes manually, through bureaucracy, because this is the "Managing Construction" chapter. But there is technically half a page on p. 668 singing the praises of version-control software, calling it "indispensable on team projects", which manages to not mention a single program you could use for it. An understandable oversight in 01994, unforgivable in 02004, but again, incompetence rather than snake oil.
- Although he pays lip service at the beginning of the book to the independence of project phases and project activities, he often conflates them later, often presuming a quasi-waterfall model (when he isn't outright advocating it), where a requirements-analysis phase is followed by an architecture phase, then a detailed design phase, then a "construction" phase, then a testing phase, and then finally a maintenance phase. This is obviously completely unlike the reality of projects like Microsoft Windows, Emacs, Linux, GCC, and Facebook. When did Facebook mostly move from detailed design to construction? Would it have been a better social-networking website if it had spent a year or two on architecture before beginning "construction"? He does kind of go back and forth on this a lot, though, sometimes advocating more incremental approaches and then contradicting himself a page later.
- Relatedly, he advocates a division of labor where "the architect consumes the requirements; the designer consumes the architecture; and the coder consumes the design." (Traditionally, though he doesn't say this, the QA tester then consumes the code.) This division of labor has been tried many times, and the companies that have tried it have been mostly outcompeted by companies with less dysfunctional divisions of labor; they mostly survive only in niches where they have legally enforceable monopolies, such as DoD cost-plus prime contractors. None of them have been able to produce products of quality comparable to things like Linux, GCC, and Facebook. I think this is the snake-oiliest part of the book.
- Code Complete's table of "Average Cost of Fixing Defects Based on When They're Introduced and Detected", table 3-1, is convincing, compelling, thoroughly footnoted with decades of literature, and completely made up. See https://softwareengineering.stackexchange.com/questions/1637... https://web.archive.org/web/20121101231451/http://blog.secur... https://www.lesswrong.com/posts/4ACmfJkXQxkYacdLt/diseased-d... https://gist.github.com/Morendil/258a523726f187334168f11fc83.... This made-up data is McConnell's major justification for advocating waterfall-like models. More recent research that investigates the question empirically instead of relying on made-up hearsay finds, by contrast, "We found no evidence for the delayed issue effect; i.e., the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction." https://arxiv.org/pdf/1609.04886 https://agilemodeling.com/essays/costofchange.htm https://buttondown.com/hillelwayne/archive/i-ing-hate-scienc....
- The section about "user interface design" is cringe-inducingly bad. He thinks you can design a good user interface up front without having working software ("The user interface is often specified at requirements time. If it isn't, it should be specified in the software architecture,") rather than incrementally responding to usability feedback from people using a working system. It's a very short section, and that in itself is eyebrow-raising; usability is a central concern of most kinds of software, and one of the most challenging aspects of software. Really, almost everything in most software should be driven ultimately by user experience and grounded out in usability testing. Games, websites, browsers, and even compilers live and die on usability. But McConnell treats it as one minor detail among many.
- The section about the "architecture prerequisite" sounds like it was written by IBM mainframe programmers in 01978, then decorated with some OO and WWW jargon. Yes, clearly the architecture should "describe the major files and table designs to be used". That makes sense. Yes, "Input/output (...) is another area that deserves attention in the architecture. The architecture should specify a read-ahead, read-behind, or just-in-time reading scheme." I mean, seriously? Note that words like "client", "server", "tier", "cache", "protocol", "network", "message", "queue", and even "process" (as in a running instance of a program) are completely missing here. It's not that he uses different terms for them; he just doesn't talk about them at all, using any words.
- He tries to discuss "fault tolerance" with a totally nonsensical example "the square root of a number", necessarily making complete hash of the topic as a result. He doesn't mention any of the techniques that actually work for achieving fault-tolerance, such as statelessness, idempotence, the end-to-end principle, transactions, journaling, fail-stopness, checksums, disk mirroring, hardware trimodular redundancy, watchdog timers, ECC, anomaly detection, network timeouts, monitoring, alarms, etc. The only exception is that he sort of mentions granular restarts. I'm restricting myself to techniques that were well-known when he wrote the first edition of the book here, excluding things like Paxos, eventual consistency, and Merkle graphs.
- There are a lot of cases where he repeats something he's heard that he evidently doesn't understand. The muddled attempt to explain fault tolerance above is one example, but we could also mention, for example, his attempt in \u00a74.1 to describe Fortran programmers writing Fortran in C++, which completely misses the actual major difficulty (it's mostly about structuring the data as arrays, not the control flow), or his remark, "Assembler is regarded as the second-generation language," devoid of the historical context to provide any meaning to it.
- One problem that I think is actually new in the second edition is its presumption that all software is object-oriented (despite paying lip service to the fact that Visual Basic [6] was the most popular language among professional programmers, many people were still programming in Ada and assembly and Cobol and C and Fortran, etc.) and that looks a bit snake-oilier from our perspective now than it did at the time. I think OO is a useful approach to software design, but if I'm writing a generic tutorial on how to design a program, I wouldn't have a step in it called "Level 3: Division into Classes" as McConnell does in \u00a75.2, because that makes my book completely inapplicable to programming in C, Go, Fortran, Rust, Racket, VB6, or Clojure, and inapplicable to much of what people do in Python, PHP, JS, Octave, and R. The snake oil here is not object-orientation but a totalizing ideology that everything must be OO; the Chapter 6 introduction says, "In the twenty-first century, programmers think about programming in terms of classes.". The way I remember it, the first edition didn't have this problem.
- This totalizing OO outlook is somewhat exacerbated by the fact that he doesn't really understand object orientation at all, so he gives a lot of bad advice, like, "A large percentage of routines in object-oriented programs will be accessor routines, which will be very short," \u00a77.4. His whole chapter 6 is about designing classes, but he never mentions the actual core concept of object-orientation, which is polymorphic message sends, presumably because although he knows they exist, he isn't really comfortable with them and doesn't understand how central they are to the OO worldview. Instead he treats classes as a newfangled synonym for CLU's "clusters" or Ada "packages". Much of the chapter is devoted to workarounds for shortcomings of C++. This isn't really "snake oil," just incompetence.
- Another problem that I'm pretty sure wasn't present in the first edition is the counterproductive recommendations of worthless IEEE management process standards in virtually every chapter. This is kind of snake-oily; these standards are of abominable literary quality and contain no useful information that could conceivably help anyone to improve the software they write. As a representative emetic example, check out IEEE 1028, recommended in Chapter 20 and again in Chapter 21. http://profs.etsmtl.ca/claporte/english/enseignement/cmu_sqa.... Unlike some other IEEE management process standards I've had the misfortune of reading, it at least doesn't seem to contain any misinformation, but that's because it manages to spend 47 pages saying nothing at all about software.
There's still much material in the book that's solid, and lots of references to good information, but it's mixed with a lot of serious misinformation, misleading analogies, and embarrassing incompetence. And it's a slog to get through so much verbiage. But it's certainly better than Clean Code. Still, now that The Practice of Programming, The Pragmatic Programmer, and A Philosophy of Software Design are out, I think there's no longer any reason to recommend Code Complete."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Clean Code vs. A Philosophy Of Software Design"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md"}},"_tags":["comment","author_kragen","story_43166362"],"author":"kragen","children":[43183638],"comment_text":"I read some of the more questionable parts of the second edition just now, and while I think there are a lot of things to criticize in it, I suspect that it's just rose-tinted hindsight, or ignorance, that made me not object to them in the first edition; I'm pretty sure most of these problems were already there:
- All the time wasted on the dumb "construction" analogy.
- The total lack of attention to open-source software, possibly because he was misled by his own "construction" analogy. There's no such thing as a freely redistributable cabinet that's extra reliable because your house shares it with the local nuclear reactor, or a rotten floor joist you can't fix without negotiating a source license. (He does discuss buying libraries, just as you can buy cabinets instead of building them.) Though this was surely also lacking in the first edition, it was a more forgivable oversight in 01994.
- Very little attention given to automated testing; we don't get to "developer testing" until chapter 22, and even that's mostly about manual testing, though there are a few offhand remarks in \u00a74.4 and \u00a79.4 about unit testing and test-first programming, with no explanation of what that means. Even when he tries to explain "test-first programming" in \u00a722.2, there's no hint that we're talking about automated testing. And we finally see mentions of "test code" and "JUnit" in \u00a722.4, and then \u00a722.5 and \u00a722.6 have information about actual automated testing, though without any actual test code. The advice on test-case design is still excellent.
- Also, very little about source control. I know this was a deficiency in the first edition because I remember the revelation of learning about RCS a couple of years after I read it. I think it actually got better in the second edition; there's a little "Version Control" section in \u00a730.2 which refers you to \u00a728.2, "Configuration Management", which talks a little bit about the problem but doesn't mention Subversion (first released October 02000), CVS (01990), RCS (01982), SCCS (01973), or even Visual SourceSafe (01994). Instead, it mostly describes implementing similar processes manually, through bureaucracy, because this is the "Managing Construction" chapter. But there is technically half a page on p. 668 singing the praises of version-control software, calling it "indispensable on team projects", which manages to not mention a single program you could use for it. An understandable oversight in 01994, unforgivable in 02004, but again, incompetence rather than snake oil.
- Although he pays lip service at the beginning of the book to the independence of project phases and project activities, he often conflates them later, often presuming a quasi-waterfall model (when he isn't outright advocating it), where a requirements-analysis phase is followed by an architecture phase, then a detailed design phase, then a "construction" phase, then a testing phase, and then finally a maintenance phase. This is obviously completely unlike the reality of projects like Microsoft Windows, Emacs, Linux, GCC, and Facebook. When did Facebook mostly move from detailed design to construction? Would it have been a better social-networking website if it had spent a year or two on architecture before beginning "construction"? He does kind of go back and forth on this a lot, though, sometimes advocating more incremental approaches and then contradicting himself a page later.
- Relatedly, he advocates a division of labor where "the architect consumes the requirements; the designer consumes the architecture; and the coder consumes the design." (Traditionally, though he doesn't say this, the QA tester then consumes the code.) This division of labor has been tried many times, and the companies that have tried it have been mostly outcompeted by companies with less dysfunctional divisions of labor; they mostly survive only in niches where they have legally enforceable monopolies, such as DoD cost-plus prime contractors. None of them have been able to produce products of quality comparable to things like Linux, GCC, and Facebook. I think this is the snake-oiliest part of the book.
- Code Complete's table of "Average Cost of Fixing Defects Based on When They're Introduced and Detected", table 3-1, is convincing, compelling, thoroughly footnoted with decades of literature, and completely made up. See https://softwareengineering.stackexchange.com/questions/1637... https://web.archive.org/web/20121101231451/http://blog.secur... https://www.lesswrong.com/posts/4ACmfJkXQxkYacdLt/diseased-d... https://gist.github.com/Morendil/258a523726f187334168f11fc83.... This made-up data is McConnell's major justification for advocating waterfall-like models. More recent research that investigates the question empirically instead of relying on made-up hearsay finds, by contrast, "We found no evidence for the delayed issue effect; i.e., the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction." https://arxiv.org/pdf/1609.04886 https://agilemodeling.com/essays/costofchange.htm https://buttondown.com/hillelwayne/archive/i-ing-hate-scienc....
- The section about "user interface design" is cringe-inducingly bad. He thinks you can design a good user interface up front without having working software ("The user interface is often specified at requirements time. If it isn't, it should be specified in the software architecture,") rather than incrementally responding to usability feedback from people using a working system. It's a very short section, and that in itself is eyebrow-raising; usability is a central concern of most kinds of software, and one of the most challenging aspects of software. Really, almost everything in most software should be driven ultimately by user experience and grounded out in usability testing. Games, websites, browsers, and even compilers live and die on usability. But McConnell treats it as one minor detail among many.
- The section about the "architecture prerequisite" sounds like it was written by IBM mainframe programmers in 01978, then decorated with some OO and WWW jargon. Yes, clearly the architecture should "describe the major files and table designs to be used". That makes sense. Yes, "Input/output (...) is another area that deserves attention in the architecture. The architecture should specify a read-ahead, read-behind, or just-in-time reading scheme." I mean, seriously? Note that words like "client", "server", "tier", "cache", "protocol", "network", "message", "queue", and even "process" (as in a running instance of a program) are completely missing here. It's not that he uses different terms for them; he just doesn't talk about them at all, using any words.
- He tries to discuss "fault tolerance" with a totally nonsensical example "the square root of a number", necessarily making complete hash of the topic as a result. He doesn't mention any of the techniques that actually work for achieving fault-tolerance, such as statelessness, idempotence, the end-to-end principle, transactions, journaling, fail-stopness, checksums, disk mirroring, hardware trimodular redundancy, watchdog timers, ECC, anomaly detection, network timeouts, monitoring, alarms, etc. The only exception is that he sort of mentions granular restarts. I'm restricting myself to techniques that were well-known when he wrote the first edition of the book here, excluding things like Paxos, eventual consistency, and Merkle graphs.
- There are a lot of cases where he repeats something he's heard that he evidently doesn't understand. The muddled attempt to explain fault tolerance above is one example, but we could also mention, for example, his attempt in \u00a74.1 to describe Fortran programmers writing Fortran in C++, which completely misses the actual major difficulty (it's mostly about structuring the data as arrays, not the control flow), or his remark, "Assembler is regarded as the second-generation language," devoid of the historical context to provide any meaning to it.
- One problem that I think is actually new in the second edition is its presumption that all software is object-oriented (despite paying lip service to the fact that Visual Basic [6] was the most popular language among professional programmers, many people were still programming in Ada and assembly and Cobol and C and Fortran, etc.) and that looks a bit snake-oilier from our perspective now than it did at the time. I think OO is a useful approach to software design, but if I'm writing a generic tutorial on how to design a program, I wouldn't have a step in it called "Level 3: Division into Classes" as McConnell does in \u00a75.2, because that makes my book completely inapplicable to programming in C, Go, Fortran, Rust, Racket, VB6, or Clojure, and inapplicable to much of what people do in Python, PHP, JS, Octave, and R. The snake oil here is not object-orientation but a totalizing ideology that everything must be OO; the Chapter 6 introduction says, "In the twenty-first century, programmers think about programming in terms of classes.". The way I remember it, the first edition didn't have this problem.
- This totalizing OO outlook is somewhat exacerbated by the fact that he doesn't really understand object orientation at all, so he gives a lot of bad advice, like, "A large percentage of routines in object-oriented programs will be accessor routines, which will be very short," \u00a77.4. His whole chapter 6 is about designing classes, but he never mentions the actual core concept of object-orientation, which is polymorphic message sends, presumably because although he knows they exist, he isn't really comfortable with them and doesn't understand how central they are to the OO worldview. Instead he treats classes as a newfangled synonym for CLU's "clusters" or Ada "packages". Much of the chapter is devoted to workarounds for shortcomings of C++. This isn't really "snake oil," just incompetence.
- Another problem that I'm pretty sure wasn't present in the first edition is the counterproductive recommendations of worthless IEEE management process standards in virtually every chapter. This is kind of snake-oily; these standards are of abominable literary quality and contain no useful information that could conceivably help anyone to improve the software they write. As a representative emetic example, check out IEEE 1028, recommended in Chapter 20 and again in Chapter 21. http://profs.etsmtl.ca/claporte/english/enseignement/cmu_sqa.... Unlike some other IEEE management process standards I've had the misfortune of reading, it at least doesn't seem to contain any misinformation, but that's because it manages to spend 47 pages saying nothing at all about software.
There's still much material in the book that's solid, and lots of references to good information, but it's mixed with a lot of serious misinformation, misleading analogies, and embarrassing incompetence. And it's a slog to get through so much verbiage. But it's certainly better than Clean Code. Still, now that The Practice of Programming, The Pragmatic Programmer, and A Philosophy of Software Design are out, I think there's no longer any reason to recommend Code Complete.","created_at":"2025-02-25T22:03:07Z","created_at_i":1740520987,"objectID":"43178132","parent_id":43175912,"story_id":43166362,"story_title":"Clean Code vs. A Philosophy Of Software Design","story_url":"https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md","updated_at":"2025-02-28T08:02:45Z"},{"_highlightResult":{"author":{"fullyHighlighted":true,"matchLevel":"full","matchedWords":["mirendil"],"value":"Morendil"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":""Research paper", ha. I came across this a few years ago, I call it the "Frankenpaper". See this gist for why I call it that: https://gist.github.com/Morendil/85336bf97211f9f31102ce2ee4e..."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"The \u201cbugs are 100x more expensive to fix in production\u201d study might not exist"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://www.theregister.com/2021/07/22/bugs_expense_bs/"}},"_tags":["comment","author_Morendil","story_27917595"],"author":"Morendil","comment_text":""Research paper", ha. I came across this a few years ago, I call it the "Frankenpaper". See this gist for why I call it that: https://gist.github.com/Morendil/85336bf97211f9f31102ce2ee4e...","created_at":"2021-07-23T22:44:41Z","created_at_i":1627080281,"objectID":"27936466","parent_id":27919003,"story_id":27917595,"story_title":"The \u201cbugs are 100x more expensive to fix in production\u201d study might not exist","story_url":"https://www.theregister.com/2021/07/22/bugs_expense_bs/","updated_at":"2024-09-20T09:03:21Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"db48x"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"Direct costs are all anyone means when they say that \u201cbugs are 100\u00d7 more expensive to fix in production\u201d. There\u2019s nothing in that statement about indirect or reputational costs, just the cost to fix. The factors you mention all exist, but they are irrelevant to the cost of fixing a bug. They are very relevant to the cost of _failing_ to fix a bug.
What is relevant is your definition of the various stages of development. The numbers that are the source of the \u201c100\u00d7\u201d figure are from the development of an anti\u2013ballistic missile system from the sixties or seventies. They would have been programming in assembler (thus the \u201c27 lines of code patched per change\u201d is not unusual). Finding and fixing a bug in the software after you\u2019ve built all the missiles and shipped them to every ballistic missile base in the US could indeed be very expensive! But if your release process is just copying the new code to a server (or even a fleet of servers) and restarting some services, then it\u2019s not expensive at all. Most of us have a very different idea of what \u201creleasing\u201d the software means than the folks on this project had.
https://gist.github.com/Morendil/f9c2e9f3f450d3a76de8aeee7cf..."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"The \u201cbugs are 100x more expensive to fix in production\u201d study might not exist"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://www.theregister.com/2021/07/22/bugs_expense_bs/"}},"_tags":["comment","author_db48x","story_27917595"],"author":"db48x","comment_text":"Direct costs are all anyone means when they say that \u201cbugs are 100\u00d7 more expensive to fix in production\u201d. There\u2019s nothing in that statement about indirect or reputational costs, just the cost to fix. The factors you mention all exist, but they are irrelevant to the cost of fixing a bug. They are very relevant to the cost of _failing_ to fix a bug.
What is relevant is your definition of the various stages of development. The numbers that are the source of the \u201c100\u00d7\u201d figure are from the development of an anti\u2013ballistic missile system from the sixties or seventies. They would have been programming in assembler (thus the \u201c27 lines of code patched per change\u201d is not unusual). Finding and fixing a bug in the software after you\u2019ve built all the missiles and shipped them to every ballistic missile base in the US could indeed be very expensive! But if your release process is just copying the new code to a server (or even a fleet of servers) and restarting some services, then it\u2019s not expensive at all. Most of us have a very different idea of what \u201creleasing\u201d the software means than the folks on this project had.
https://gist.github.com/Morendil/f9c2e9f3f450d3a76de8aeee7cf...","created_at":"2021-07-23T05:31:32Z","created_at_i":1627018292,"objectID":"27927536","parent_id":27917893,"story_id":27917595,"story_title":"The \u201cbugs are 100x more expensive to fix in production\u201d study might not exist","story_url":"https://www.theregister.com/2021/07/22/bugs_expense_bs/","updated_at":"2024-09-20T09:02:27Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"asadotzler"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"Morendil, his comments are often very much directed at individuals and not at features or bugs.
Calling a developer a \"simian\" and shouting \"screw you\" and actually saying \"You know, every time I see a comment from [a specific Thunderbird developer] I just want to reach out through the intertubes and cut off his damned fingers to prevent him ever writing any code\" are all direct and personal attacks that should not be tolerated in any forum.
There's nothing \"funny\" about that. It's the behavior of a bully and someone who thinks that because he's big bad programmer with a long history that he can verbally abuse other programmers when ever he feels like it.
There's nothing funny about bullying."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Mozilla now banning people for grumpy bug reports"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://bugzilla.mozilla.org/show_bug.cgi?id=668655#c1"}},"_tags":["comment","author_asadotzler","story_2741660"],"author":"asadotzler","children":[2742276],"comment_text":"Morendil, his comments are often very much directed at individuals and not at features or bugs.
Calling a developer a \"simian\" and shouting \"screw you\" and actually saying \"You know, every time I see a comment from [a specific Thunderbird developer] I just want to reach out through the intertubes and cut off his damned fingers to prevent him ever writing any code\" are all direct and personal attacks that should not be tolerated in any forum.
There's nothing \"funny\" about that. It's the behavior of a bully and someone who thinks that because he's big bad programmer with a long history that he can verbally abuse other programmers when ever he feels like it.
There's nothing funny about bullying.","created_at":"2011-07-08T10:04:57Z","created_at_i":1310119497,"objectID":"2741846","parent_id":2741828,"story_id":2741660,"story_title":"Mozilla now banning people for grumpy bug reports","story_url":"https://bugzilla.mozilla.org/show_bug.cgi?id=668655#c1","updated_at":"2026-09-21T06:13:27Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"hyperpape"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"Here is more from Laurent Bossavit, showing the history of shoddy citations surrounding the 100x claim: https://gist.github.com/Morendil/f9c2e9f3f450d3a76de8aeee7cf...."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Forcing Functions in Software Development"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://coderefinery.wordpress.com/2020/10/21/forcing-functions-in-software-development/"}},"_tags":["comment","author_hyperpape","story_24845339"],"author":"hyperpape","comment_text":"Here is more from Laurent Bossavit, showing the history of shoddy citations surrounding the 100x claim: https://gist.github.com/Morendil/f9c2e9f3f450d3a76de8aeee7cf....","created_at":"2020-10-21T19:35:52Z","created_at_i":1603308952,"objectID":"24851228","parent_id":24848592,"story_id":24845339,"story_title":"Forcing Functions in Software Development","story_url":"https://coderefinery.wordpress.com/2020/10/21/forcing-functions-in-software-development/","updated_at":"2024-09-20T07:08:47Z"},{"_highlightResult":{"author":{"fullyHighlighted":true,"matchLevel":"full","matchedWords":["mirendil"],"value":"Morendil"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"Now translated here:
http://morendil.github.com/folklore.html"},"story_title":{"matchLevel":"none","matchedWords":[],"value":"The industry as a whole makes its choices on the basis of folklore"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"http://raganwald.posterous.com/i-cannot-rightly-apprehend-the-confusion-of-i"}},"_tags":["comment","author_Morendil","story_2039510"],"author":"Morendil","comment_text":"Now translated here:
http://morendil.github.com/folklore.html","created_at":"2011-01-05T18:47:01Z","created_at_i":1294253221,"objectID":"2071945","parent_id":2039669,"story_id":2039510,"story_title":"The industry as a whole makes its choices on the basis of folklore","story_url":"http://raganwald.posterous.com/i-cannot-rightly-apprehend-the-confusion-of-i","updated_at":"2024-09-19T17:26:13Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"alangpierce"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"If you search "Counting Defects" in the pdf posted by Morendil ( https://pdfs.semanticscholar.org/feb0/0dd349ad701e1e4045282b... ), you get some of the methodology on page 78 (the page with "78" written on it, not PDF numbering):
> When a reviewer or consensus of reviewers determines that code must be changed before it is acceptable, it is a \u201cdefect.\u201d If the algorithm is wrong, it\u2019s a defect. If the code is right but unintelligible due to poor documentation, it\u2019s a defect. If the code is right but there\u2019s a better way to do it, it\u2019s a defect. A simple conversation is not a defect nor is a conversation where a reviewer believed he found a defect but later agreed that it wasn\u2019t one. In any event a defect is an improvement to the code that would not have occurred without review.
I'd say that's a bit looser of a definition than I'd prefer, but it's at least good that the study didn't try to use some metric like "number of inline comments", since often times I use inline comments for praise or to mention possible alternatives that may or may not be any better than the code."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"A bogus study on code review"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"http://blog.wesleyac.com/posts/bogus-code-review-data"}},"_tags":["comment","author_alangpierce","story_15967279"],"author":"alangpierce","comment_text":"If you search "Counting Defects" in the pdf posted by Morendil ( https://pdfs.semanticscholar.org/feb0/0dd349ad701e1e4045282b... ), you get some of the methodology on page 78 (the page with "78" written on it, not PDF numbering):
> When a reviewer or consensus of reviewers determines that code must be changed before it is acceptable, it is a \u201cdefect.\u201d If the algorithm is wrong, it\u2019s a defect. If the code is right but unintelligible due to poor documentation, it\u2019s a defect. If the code is right but there\u2019s a better way to do it, it\u2019s a defect. A simple conversation is not a defect nor is a conversation where a reviewer believed he found a defect but later agreed that it wasn\u2019t one. In any event a defect is an improvement to the code that would not have occurred without review.
I'd say that's a bit looser of a definition than I'd prefer, but it's at least good that the study didn't try to use some metric like "number of inline comments", since often times I use inline comments for praise or to mention possible alternatives that may or may not be any better than the code.","created_at":"2017-12-24T16:39:32Z","created_at_i":1514133572,"objectID":"16000164","parent_id":16000026,"story_id":15967279,"story_title":"A bogus study on code review","story_url":"http://blog.wesleyac.com/posts/bogus-code-review-data","updated_at":"2024-09-20T01:46:49Z"},{"_highlightResult":{"author":{"fullyHighlighted":true,"matchLevel":"full","matchedWords":["mirendil"],"value":"Morendil"},"title":{"matchLevel":"none","matchedWords":[],"value":"Fact and folklore in software engineering"},"url":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["mirendil"],"value":"http://morendil.github.com/folklore.html"}},"_tags":["story","author_Morendil","story_2072164"],"author":"Morendil","children":[2072252,2072263,2072283,2072300,2072309,2072311,2072356,2072366,2072401,2072424,2072465,2072554,2072731,2072740,2072799,2073229,2073313,2073721,2073751],"created_at":"2011-01-05T19:42:17Z","created_at_i":1294256537,"num_comments":90,"objectID":"2072164","points":135,"story_id":2072164,"title":"Fact and folklore in software engineering","updated_at":"2023-09-06T19:07:47Z","url":"http://morendil.github.com/folklore.html"},{"_highlightResult":{"author":{"fullyHighlighted":true,"matchLevel":"full","matchedWords":["mirendil"],"value":"Morendil"},"title":{"matchLevel":"none","matchedWords":[],"value":"An apology to readers of Test-Driven iOS Development"},"url":{"matchLevel":"none","matchedWords":[],"value":"http://blog.securemacprogramming.com/2012/09/an-apology-to-readers-of-test-driven-ios-development/"}},"_tags":["story","author_Morendil","story_4474166"],"author":"Morendil","children":[4474234,4474235,4474271,4474274,4474295,4474340,4474373,4474377,4474397,4474441,4474444,4474544,4474553,4474675,4474730,4474769,4474872,4474914,4474952,4475151,4475810,4475887,4475889,4476011],"created_at":"2012-09-04T12:01:49Z","created_at_i":1346760109,"num_comments":67,"objectID":"4474166","points":231,"story_id":4474166,"title":"An apology to readers of Test-Driven iOS Development","updated_at":"2024-09-19T18:51:12Z","url":"http://blog.securemacprogramming.com/2012/09/an-apology-to-readers-of-test-driven-ios-development/"},{"_highlightResult":{"author":{"fullyHighlighted":true,"matchLevel":"full","matchedWords":["mirendil"],"value":"Morendil"},"title":{"matchLevel":"none","matchedWords":[],"value":"What a scientist didn't tell the New York Times about his study on bee deaths"},"url":{"matchLevel":"none","matchedWords":[],"value":"http://money.cnn.com/2010/10/08/news/honey_bees_ny_times.fortune/index.htm"}},"_tags":["story","author_Morendil","story_1774592"],"author":"Morendil","children":[1774759,1774811,1774833,1774855,1774922,1774937,1775130,1775131,1775186,1775235],"created_at":"2010-10-09T07:34:17Z","created_at_i":1286609657,"num_comments":41,"objectID":"1774592","points":132,"story_id":1774592,"title":"What a scientist didn't tell the New York Times about his study on bee deaths","updated_at":"2023-09-06T20:07:06Z","url":"http://money.cnn.com/2010/10/08/news/honey_bees_ny_times.fortune/index.htm"}],"hitsPerPage":20,"nbHits":138,"nbPages":7,"page":0,"params":"query=mirendil&advancedSyntax=true&analyticsTags=backend","processingTimeMS":9,"processingTimingsMS":{"_request":{"roundTrip":15},"afterFetch":{"format":{"highlighting":3,"total":3},"merge":{"mergeLoop":{"prepareNextHit":3,"total":3},"total":3},"total":3},"fetch":{"query":3,"total":4},"total":9},"query":"mirendil","serverTimeMS":13}