Facts and Fallacies of Software Engineering

Sarusa writes "The title of the book, Facts and Fallacies of Software Engineering, is nice and controversial, and so is the content. Robert Glass is a long-time software engineer and researcher into what software practices work, which don't, and why. You'll find his name all over the literature along with names like Yourdon and Brooks, and he's got a long list of professional credits. In other words, he's an experienced, cranky, opinionated old coot who pulls no punches and writes a very readable and useful book. And he's on your side, having deliberately passed up a more lucrative career in management for a technical track." Read on for the rest of Sarusa's review. Facts and Fallacies of Software Engineering author Robert L. Glass pages 190 publisher Addison-Wesley rating 8 out of 10 reviewer Sarusa ISBN 0321117425 summary 40 years of software engineering research in a nutshell.

The Layout

Facts and Fallacies is not a technically demanding book; it's a very easy and compelling read. There are 55 Facts (and 5+5 fallacies) grouped into logical sections such as Management, Life Cycle, and Quality.

First, each Fact is stated succinctly. (For instance, Fact 1: The most important factor in software work is not the tools or techniques used by the programmers, but rather the quality of the programmers themselves.) Then the point is fleshed out more fully -- in this case, that even with all the periodic hype for some hot new methodology that promises orders of magnitude greater productivity, the quality of your programmers matters far more than anything else (and even the best new methods only offer 5-35% increases).

Next, the level of controversy about this Fact is discussed. For Fact 1, it's that even though everyone pays lip service to the idea of people being more important than processes, we all still act like it's not true. Maybe this new hot methodology can turn all your lousy programmers into great ones! Perhaps it's because people are a harder problem to address than tools, techniques, and process. And, of course, hot new methodologies sell a lot of books.

Finally comes a list of sources and references, which can lead you to more in-depth great reading like Peopleware and Software Runaways. This all works out to about one to two pages per item.

The Facts and Fallacies

The Facts and Fallacies fall into several groups. Some are not well known (or just met with stunned disbelief) such as Fact 31: Error removal is the most time-consuming phase of the life cycle. Some that are pretty well accepted, but are mostly ignored, like Fact 1 above. Some that are accepted, but nobody can agree on what to do about (if anything), like Fact 9 (paraphrased) #150: Project estimates are done at the beginning of the project when you have insufficient understanding of the requirements and scope, which makes it a very bad time to do an estimate for the entire project.

Some Facts Glass acknowledges many people will flat out disagree with (and for a few people, very loudly), like Fact 30: COBOL is a very bad language, but all the others (for business data processing) are so much worse. These are the Facts where he really has an axe to grind, and make for amusing reading. In this case what he's really saying is that there is a use for domain-specific languages intended to do one specific thing and do it well, rather than languages like C and Java which attempt to be "good enough" for any use under the sun. But everyone hates COBOL, including me, so it's controversial.

What's Good?

Again, this is a good (and fast) Read. Even if you don't agree with everything, Glass is a skilled writer with strong opinions and a sense of humor. And you might end up agreeing more than you expected. I was pretty skeptical when I started reading. After all, I'm a long time software engineer with strong opinions too, and how often do you get opinionated geeks to agree on even what soda or text editor to use? But most of the Facts resonated with my experience, and of course for most of them Glass has substantial research reference for. The best Facts are those that you knew but might never have expressed explicitly, like Fact 41: Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.

Or consider Fact 18: There are two 'rules of three' in reuse: (a) it is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library. I knew this generally, and you probably did too, but I didn't know the specific reference for "Biggerstaff's Rules of Three," which give you a ballpark figure.

The book was written in 2002, when eXtreme Programming was hot, and it's very interesting that the predictions Glass made in this book about the strengths and weaknesses of XP were, in retrospect, pretty much on target, and this sort of predictive success helps confirm more viscerally that he knows his subject.

What's Bad?

There are a few Facts in here that Glass included just because he feels strongly about them (or even about specific people) and he doesn't really back them up very strongly except with "well golly, this is so obvious." Like Fallacy 5: Programming can and should be egoless. Note that this is a Fallacy, so he opposes it. I happen to agree with him, but his arguments are mostly personal ox-goring even if they're based on his extensive experience. Still, it's an interesting read.

A few of the Fallacies he feels are so obvious that he doesn't even really bother providing sources or references for them, and this somewhat diminishes the overall feel of rigor.

Really, the worst thing about this book is that it doesn't come with a poster of just a bullet-pointed list of facts and fallacies that you can nail to your office wall (or your boss's).

A Few More Facts

Just to whet your appetite:

Fact 21: For every 25% increase in problem complexity, there is a 100% increase in solution complexity.

Fact 37: Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run. [But are so mentally and emotionally exhausting that we rarely do them.]

Fallacy 10: You teach people how to program by showing them how to write programs. Why don't we teach them to read programs first? Good question (and he has a few possible answers).

In Conclusion

I wouldn't say this Facts and Fallacies of Software Engineering is quite as powerful as The Mythical Man Month, Peopleware or Death March on their own, but if you program (or manage programmers) and want to be more than just a code pig, this will give you the condensed version of 40 years of research in a very readable package. Even if you don't agree with everything he says, it's well worth considering it.

You can purchase Facts and Fallacies of Software Engineering from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.

Comments

Fact 37 - code reviews catch errors

[tcopeland]

> Fact 37: Rigorous inspections [code reviews]
> can remove up to 90% of errors before the
> first test case is run. [But are so mentally
> and emotionally exhausting that we
> rarely do them.]

I think some of these terms mean different things to different people. When he says "test case", he means (I think) a tester clicking around a UI and adding a new employee or whatever. But "test case" can also mean a unit test, i.e.:

Employee e = new Employee("Fred");
assertEquals(e.getName(), "Fred", "Name not set correctly on instantiation");

The latter meaning of unit test provides a way to do "rigorous inspections" over and over - because a computer is doing the work. Good times.

Re:Fact 37 - code reviews catch errors

[William Tanksley]

Also needless to say that unit tests become exponentially useless when the complexity of the code doubles.

This is hardly "needless to say". You'll have to justify it if you're going to get me to believe it; I don't have data (so I'm vulnerable to any studies you post), but you'll have to at least counteract these reasons:

• Unit tests always verify the leaf nodes well (the primitives and the functions that only call primitives), by a constant amount independant of the overall complexity.
  
• Branch nodes (functions that call the leaf nodes) benefit from being able to call verified code. Debugging the branch nodes is easier when you have some level of confidence in the leaf nodes.
  
• The unit tests for the branch nodes also test the leaf nodes. As the complexity increases, confidence in the low level nodes must also increase.
  
• The unit tests for each branch node will be as complex as the new functionality added by that branch node. If the node is complex, the test will be complex -- but if the node is complex, its design is BROKEN, and perhaps having that problem show up in the test is a good thing. If the test is that complicated, think of how complex the use case must be, and the documentation, and the actual code that has to call the function?
  
• Unit tests make code modification much simpler and more testable. Without a unit test, you can't know whether your change preserves even the simplest of the properties of the old code. With unit tests throughout the code, you can be certain that every programmer's old expectations are met by your new changes.

They also tend to 'pollute' the code obscuring actual logic and making it hard to follow.

No, they don't. Are you under the impression that unit tests have something to do with conditional debug statements? They have NOTHING to do with each other.

Unit tests sit outside the code. They, in fact, should be written as examples of correct and expected use of the code in question. Whenever you want to reuse some code, you can scan through that code's unit tests, and imitate the use you see there. If you don't see any use that's like what you're planning, you know the code doesn't support what you want; you should either add some new unit tests to the old code (and expect to have to modify the code to satisfy your new tests), or decide to write new code after all.

BUT -- I think code reviews are important.

-Billy

Re:What bugs me..

[Anonymous Coward]

Woodfield, Scott N. 1979 "An Experiment on Unit Increase in Problem Complexity." IEEE Transactions on Software Engineering, (March)

Re:Algorithmic-Based Programming Is Wrong-Headed

[photon317]

Uhm... I have a hard time taking that guy's stance on software development seriously when the same site also hosts the following rather, uhm, interesting [whacked the fuck out] paper: http://users.adelphia.net/~lilavois/Seven/bible.ht ml

Some other good resources on the topic... (BSP)

[under_score]

This is Blatant Self Promotion (you have been warned).

Here's a good list of software resources, mostly books that I've collected over the last five years or so. Lots of stuff about agile, stuff for managers as well as developers.

A similar read

[jefu]

A book in the same kind of vein is "A handbook of Software and Systems Engineering -- Empirical Observations, Laws and Theories". In it, "laws" are stated and discussed with emphasis on experiments or studies that back up the law, or that tend to falsify it.

As an example, one of the laws mentioned in this discussion is given as "Individual developer performance varies considerably." (Law 31) Then some statistics are given showing the variability. Finally there is a comment on if we should or should not trust the numbers given.

Change font type and size...

[DarkMan]

If printing it out is not an option, displaying it in a different font, in a different size, ideally with differnt line breaks (hard for code, possible for other things) is almost as good.

The aim of printing or reformating is to change the text, and force you to actually read the letters that are on the page. This is done by destroying the patterns in the positioning of the text that the writer is used to, thereby hindering recall.

This is one of the reasons LaTeX is useful (for me, at any rate), because it does all of the above, without actually printing it (written in 10 pt monospaced Courier, read is 12pt Times New Roman, 1.5 spaced, paginated). Most literate programming schemes also have this as a side effect, notably Web derived scheme which output LaTeX. I've always wondered how much that contributes to the sucess of those methods.

Re:COBOL

[biobogonics]

I saw the word COBOL and cringed and immediately thought of long hot days in the arid lab. Also, spending enormous amounts of time programming/debugging on what I thought was the worst language ever. Master file update...almost makes me cry what they put us through...

Modern COBOLs are a far cry from the original language. Some even have OO features. While the thought of using traditional COBOL file management makes me cringe too, nowadays you can use SQL or call out to an ODBC driver. Probably the best feature of the language is its data types. You are guaranteed to have (what appears to be) decimal arithmetic of specified precision. Good built in and external products are available for creating GUIs. While I would not consider it a general purpose programming language, in fact several COBOL compilers and associated tools are written in COBOL.

Similarly, modern Fortran (90 & 95) is a much more capable language then the 66 or 77 standard versions. I would prefer to use it rather than C or C++ in numeric computation.

I'm sure the author is trying to make the point "use the right tools for the job".

And use a grinder

[devphil]

Which is what we used to call pretty-printers when they did more than just wrap everything in font tags.

My favorite was lgrind, which produced TeX/LaTeX versions of your source. It could be taught about variable naming patterns, so if your code does something like "delta_vn = blah", it would emit "\delta_{vn} = blah". When printed, this becomes an actual Greek delta character, with the "vn" as a subscript. (Just one example.)

Checking the formula in the code against the formula in the math reference is a lot easier when the formula in the code looks like the math. :-)

Re:Copyright problems

[Anonymous Coward]

The Lions' book (until fairly recently) wasn't even a real book. The reason was the copyright. A couple of years back, OldSCO actually allowed it to be published as a book.