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.
You could have shortened that to "experienced"; the rest follows naturally from that.
Sheesh, evil *and* a jerk. -- Jade
...this one by Mike Cohn of Mountain Goat Software.
Mike's review is from the "agile software" point of view, so he comments favorably on (among others) Fact 22 - "Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical".
The Army reading list
It's like the 80/20 rule...it's a ROM (Rough Order of Magnitude).
No, it's not an exact figure, but it sure got his point across as to
an approximation of the relationship, didn't it?
Could someone please point out to me where in the Constitution, exactly, is the "Right To Not Be Offended"?
If he was in management, wouldn't he have more influence which he could use to change things for the better? Just because you have a management position doesn't automatically mean that you believe in the PHB management style.
Remember the days when Republicans were the party of fiscal responsibility?
> 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.: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.
The Army reading list
In fact, I've generally held that the complexity of implementation is generally an exponential function of the general complexity of the problem. Allowing additional degrees of freedom in a design is typically very expensive. You aren't just adding that additional degree of freedom to the design, you have to make the rest of the design aware of that new dimension and put it into implementation.
...the worst system except for all the others.
If a code review, which takes several hours of my time and the time of my fellow developers, can catch 90% of the errors before the first test case is run, or I can catch 90% of the errors (not necessarily the same ones) using the test cases, it's a better use of resources to let the computer point the errors out to me.
A code review on "90% debugged" software that finds an error strikes me as more useful than a code review that finds several errors in 0% debugged software.
As for fact #1, good process or tools may not be able to make all programmers gods, but bad process or tools can make a mortal out of anyone.
Addendum: Unless you are talking about a Microsoft product where for every 1 % increase in problem complexity, there is a 7 year delay in solution delivery.
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.
Fallacy 5: Programming can and should be egoless
I have worked with somebody who turned himself into a great programmer by being egoless. He could solve any problem by the simple expedient of not trying to do it all himself and being very good at accepting ideas from other people. In most circumstances programming is done within a team and ego just gets in the way.
Who wants to work with somebody who rejects an idea just because they didn't think of it!!.
At university I and a friend invented the IRS.
We smoked pretty heavily in those days (cigarettes) and felt a need to justify it.... 87% of Nobel prize winners are smokers. Furthermore, children who smoke are more likely to get GCSE grades A to C; non-smoking prisoners reoffend more often. In fact smoking cures AIDS. And cancer.
All these came from the sound research of the IRS (Institute for Random Statistics). We got pretty far down the list with some people.
I think a book like this is what is wholly necessary. I am not saying this book does a good job of it (I haven't read it). There just needs to be a book that tells people how much of the software engineering information is false and unnecessary. This is so we don't have to either sift through all of it or even worse waste countless hours trying to follow a faulty discipline.
Yea I have an agenda because writing software is hard enough in itself. It is 10 times worse when cluttered with overhead. I remember my very first programming class in high school (it was at a community college) where I was told for a FACT that I should flowchart every function and include a separate box for every line of code. It is ridiculous and they are feeding this stuff into students heads as fact.
Some are poorly organized in everything but their code (*ahem*.) A few grew up believing that an employee / employer relationship should be antagonistic; that a manager must rule their team with an iron fist. That may come from looking around at a bunch of us slacker programmers thinking "hey, why aren't they working as hard as I? If I were their manager, I'd be busting their asses 24 by 7." Many are extremely introverted and have trouble speaking up among their peers; they simply would not be capable of dressing down an employee who desperately needs it.
In most of these cases it seems that the programmers have spent their time learning machine management skills. Those skills are completely unhelpful when it comes to working with people. The lessons you learn (for example, "the machine only does exactly what I tell it") don't work with human employees, no matter how hard you try to apply them.
Yes, management is a skill that can be learned, but I don't know any geeks that would want to spend the time, let alone actually manage. Not even for the money. Almost all the people I know who have become successful managers have never been real programmers. They were business analysts or came from completely outside the IT field.
John
After writing out a couple hundred lines of code, print it out. Then come in the next day and read it. I mean, truly read it, line by line.
Some may argue that this is not as good other programmers reading the code. Undoubtedly true, but you will still catch many errors. The fact that you've waited a day means you are, in a sense, a different programmer than the one that wrote the code. And the fact that it's printed rather than on the screen gives you a different perspective.
I suggest that running tests is not sufficient to ensure a reasonable level of quality. There are certain errors that are unlikely to be caught by testing, and yet are quite obvious in a read through.
In other word, testing is not a replacement for read throughs. In finding problems, a multi-faceted approach is needed.
How do you propose a geek go about staging a coup de corp?
Attain some social skills, go out and play some golf and buy the boss a beer.
Noone wants to work with arrogant anti-social types, management included.
I don't need no instructions to know how to rock!!!!
This message paid for Swift Byte Programmers for Truth.
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).
Or your boss.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
If the manager imposes an impossible deadline to the programmer, hes just a bad boss, PHB style. Of course, there are always real world time constraints to be met, but in this case the manager should define a possible goal along with the programmer, alternative solutions, scope agreements, etc.
On the other hand, if the programmer is incapable of defining a deadline himself to a well defined amount of work, than you just cant blame the manager.
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
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.
This is what separates the men from the boys. Estimation of project requirements are not perfect until the project is complete, so you have no choice but to work with educated guesses.
Modern project management is an exercise in managing uncertainty.
It is easy to say how long it would take you to write a script, anyone can do that in their head: guess base on experience, multiply by x2 and have a reasonable estimate.
Now try estimating a thousands scripts (or circuits) done by hundreds of engineers of varying aptitudes that will result in a capital cost of several billion dollars over (hopefully) a few years! All of which is directly reflected in your retirement investments!
That kind of planning is real nuts-and-guts stuff that most of us well never have to wrestle with, and a "fact" like this grossly understates and misrepresents.
Programming is easy.
Planning is orders of magnitude harder by comparison.
I prefer programming, the latter makes my brainpan throb.
https://www.accountkiller.com/removal-requested
"The reason most geeks don't want to manage is simple..It is HARDER than coding."
Management is not harder than coding per se. It is just harder for geeks whose talents and interests are more suited for coding. Most managers don't want to code, because for them it is HARDER than managing.
---------
There is inferior bacteria on the interior of your posterior.