Slashdot Mirror
Facts and Fallacies of Software Engineering
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 FallaciesThe 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.
We had a Book Club at my job, where we reviewed one to four Facts or Fallacies at each meeting, once a week. We collected comments and suggestions about how to change how we worked. It was really interesting, and it was good to engage more people in the discussion, because while I might really care about this stuff and have strong opinions, other people in our organization did not have strong opinions and actually started to think about this stuff as a result of our meetings.
Unfortunately, our suggestions didn't really get anywhere as a Massive Reorganization (TM) of the department took place. *grumble*
We're thinking of doing another Book Club, talking about the "Dynamics of Software Development" by Jim McCarthy.
Education is the silver bullet.
Let's assume that the book's thesis is true that COBOL is best for administrative programming since it's a specialised language.
Does the book address e.g. Lisp, where programmers have a standard "pattern" to create sub-languages to attack problems?
It sounds like an argument that Lisp should be used instead of COBOL, since Lisp is arguably at least as good as any/most for non-low level programming.
Now I'll probably be flamed by Lisp people... :-)
Karma: Excellent (My Karma? I wish...:-( )
The main reason programmers appear to have an ego about their work is that as you get older and more experienced you're expected to know more about software engineering than the people younger or less experienced than you. Never mind that you've never worked with Package X, you are a senior guy and you can handle it. They also have their junior people lean on you and then their success depends on yours.
If you appear egoless and unashamed to draw from others' advice, you appear to be ignorant and unmotivated once you get to be a certain age or get a certain amount of experience.
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).
This is exactly what John Lions was trying to do with his commentary. And he used nothing less than the Unix kernel source code as an example of well-crafted, and very readable, code.
Rest in peace, John. Your little project helped more hackers than you could ever have known in this life.
Technically, a fact is not "a true statement". A fact is a statement that is either objectively true OR objectively false, but cannot be both. This is as opposed to an opinion, which is subjective and can thus be simultaneously true for one person and false for another.
You are acting as if "fact" is the opposite of "false". It's not. "Fact" is the opposite of "Opinion".
"The earth's moon is made from green cheese" is a fact. It happens to be a false fact, but it is still a fact instead of an opinion.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
I am also an EE.
;)
Some jurisdictions do allow Software Engineering. APEG-BC (The Association of Professional Engineers and Geoscientists of British Columbia) lets Software Engineers register. UVic (University of Victoria) grants a four-year B.Eng in Software Engineering. Other universities in BC offer the same degree. I didn't go to these other places, so I don't have any details on them.
Other places in Canada offer B.Eng degrees in Software. I'm sure that there are accredited institutions in other countries that provide Software Engineering degrees. (B.Eng, not B.Sc)
Now, those NSE and MSCE guys are a different story.
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
More often I think folk don't understand what a 25% increase in complexity really is. Once you have a valid framework to make this evaluation it is easier to see how this relationship works, well, after you evolve some way of evaluating solution complexity as well...
"Talk minus action equals nothing" - Joey Shithead, D.O.A.
"Talk minus action equals
Except most programmers I know that are worth their weight in salt would completely and totally suck to have as managers.
Yep. My experience of fellow computer programmers is the same. They would not make good managers. And, more importantly, they would not ENJOY being managers. They are perfectly content to be managees.
However, the few programmers who are both capable and motivated to be in management really should aspire to do so, IMAO. They are exactly the sort of management that the industry needs, will likely encounter great success, and could serve as beneficial trend setters.
$1.00/50
Wow, that was almost a sad experience, reading that (and also you must read this). They go on and on about how bad algorithms are... and create an alternate system that still runs on algorithms, only instead of concentrating on a clean implementation they have this amazingly obscured one that will guarentee the impossibility of any human ever understanding a COSA "program", by taking componentization to truly absurd levels. They have successfully hidden the algorithms from themselves, perhaps, but I still see them, and they will still be bitten by them.
It would be funny if it weren't also sad.
Brooks still reigns and there remains no Silver Bullet. Wake me when these guys have a decently complex program that is better than anything I can come up with in Python. (Don't miss that second clause; making a program do something in 2004 is nothing special. It needs to be better. Handwaving is not an OS.)
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?
For the same reason we don't teach people how to write books by telling them to go read: If they're serious about writing, they're *already* avid readers. Teaching them to read would be redundant.
If a wannabe programmer isn't already reading code for ideas then he's wasting your time asking how to be a programmer.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.