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.
is random claims like 'For every 25% increase in problem complexity, there is a 100% increase in solution complexity.'
Where do they get these figures?
BTW First post!!
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...and then there was Assembler. I'll be interested to check this book out for the COBOL section alone.
I say we just grow up, be adults and die.
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.
See those little green circles in the picture at the top of the page? Guess what's inside them. Algorithms
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.
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
Declarative is effective in some domains (I would classify regular expressions as declarative programming). But I hesitate to believe that it is the best tool for all problems. Even if you ignore performance issues.
Does anyone esle find it incredible that this reviewer complains that the cranky old coot author doesn't bother to provide justifications where he really doesn't have anything compelling to add?
Knowing when to shut up is one of best indicators that someone cares enough about their subject matter that they don't feel the need to "fill air" as if other people can't supply their own experience.
I heartily condone the approach: here's what I think, take it or leave it.
I'm an old coot myself, and I've learned that it's generally a waste of time to write toward an audience that won't think for itself. If you boss won't think, a poster of convenient sound bites won't solve any problem that matters.
It has to do with the old practice of using the algorithm as the basis of software engineering. For an alternative approach to software construction, check out the info at this site: The Silver Bullet
Then I take it this suggests a new computing model that's not equivalent to the Turing model. Hmm. Nope. Looks like somebody just rediscovered declarative programming. Not that this idea is neccesarily bad. Declarative programming doesn't get used enough.
The author seems to have a bunch of fundamental misunderstandings. For one, he for some reason seems to think that all hardware is developed by plugging together logic circuits (guess he forgot that microcode stuff), and that it works perfectly (bwahahahhaha). For another, as I suggested in the first sentence, he seems to not understand that these hardware circuits are logically equivalent to the software, which is all logically equivalent to the Turing machine. It was also very confusing until I realized that by "algorithmic" he really meant "procedural". If he's found problems with that, well join the club. What makes this site most amusing though is that, after saying the problem is procedural programming, he then proceeds to reinvent concepts from object-oriented, declarative, and functional programming.
I do congratulate the author on realizing that procedural programming has problems. I also congratulate him on independently reinventing some great programming concepts. At the same time I have to say, sorry, you have not found the silver bullet. If he's really interested though, it would be great if he did language research. Functional languages are great to work with, and I think declarative programming would be good for doing a little sanity checking in large programs. His networking idea might also bear out a new programming model (although when I put some thought into it a few years ago, it seemed the same as object-oriented programming).
(And after writing all that I noticed you're the author. Anyways, I'm sorry but you haven't found the silver bullet. I like your thought process though. If you keep looking for new models you might come up with something.)
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.)
What's wrong with UML and Rational Rose? I've just come back to a project from 3 years ago that I designed and developed by myself. Nobody else has touched it since. I'm so thankful I used Rational Rose to create UML diagrams for my documentation as it's made my learning experience with everything I'd forgotten much easier. When used properly, UML doesn't confuse people. Either that or the people have been educated about it.
Extreme Programming advocates code reviews as a good practice. In fact, code reviews are part of the point behind Pair Programming. If code reviews are good, let's review all the time.
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.
Technically, computer science and computer engineering are (or should be) distinct, in the same way that chemistry and chemical engineering are distinct. Most people I know with CS degrees fall somewhere in between the two. Some universities seem to focus more on the science end (in many cases the CS dept grew out of the math dept, CS -- as opposed to computer engineering -- is basically mathematics); some focus more on engineering.
I don't see why you would consider your trade degraded because some people calling themselves computer engineers are more computer scientists. I didn't find EE inherently more (or less!) challenging than CS, it just used different abilities.
It's been my experience that it helps to have both computer scientists and computer engineers on any project that's sufficiently complex to be interesting, because they tend to have complementary knowledge and abilities.
Yeah, you're probably right. Who wouldn't want to be able to take summers off and work only a few hours a week... Who wouldn't get into the prospect of being able to crush the dreams of the young with one mighty sweep of the grading pen, to be able to blather on and on about his ideas for hours at a time, while young people are forced to listen respectfully? Who wouldn't want to spend the rest of his life on a college campus, with his own cozy little office tucked away in an ivy covered building, able to hobknob and go to cocktail parties and conferences, be addressed as "professor" or "doctor" and whatnot? Not having to worry about building software that actually WORKS, able to fart around with little academic proof-of-concept work, writing an occasional paper almost no-one will read...
Now that you mention it, hell yeah, I want to be a professor too. Sounds easier than MY job...
Farewell! It's been a fine buncha years!
Managing means keeping two dozen balls in the air simultaneously. It's not a glamour job. It's a sucky job. If you think your manager is overpaid, just think about that list above, realize that's only the visible portion of what your manager has to do, and then be really really glad it's not you.
I'm a manager of a large department. I didn't ask to be promoted -- it was thrust upon me. Managing is 30% more work for 10% more pay. I stick with it mostly because it looks good on a resume. The most frustrating thing is being judged based on the performance of others.
-a
Being a programmer myself, let me shed some light on why and when it may look when someone is working at low speed. Or really is procrastinating.
1. The obvious, they are not a great programmer after all.
2. You mention fatigue. You're dead on. Being tired can sap someone's efficiency (including via increasing the number of bugs) a lot. Whipping a team into working 12 hour shifts, 7 days a week, may work for a week, maybe even two, but then you have tired _and_ demoralized people.
3. Morale problems. Being an intelectual activity, and not just something like digging dirt or flipping burgers, you can't just whip and shout some serfs and get results. Low morale can sap someone's efficiency _a_ lot. Or bring them in a "ah, wth do I bother anyway?" road to procrastination.
Morale is hard to build, but very easy to destroy. Sometimes the easiest road to destroying it is taking a ham fisted approach and trying to force people to be cheerful.
E.g., asking people to come to mandatory team building meetings in their free time, is a great way to make the team hate each other. You can't force people to be friends. And imposing on their free time or money just builds resentment.
Doubly so if it's done in a condescending or insulting way. "Hey, we're paying for a cheap buffet, so that's your pay for being here. Of course you're not supposed to put it on your timesheet." Eh. I'm not a beggar. I can pay for my own food, _when_ I need it. Right now I needed more to be at home.
E.g., ego masturbation meetings ("status report meetings") where only one person is supposed to speak, don't really build up morale. They are actually perceived as just that: public verbal masturbation. Any one-way information exchage, that doesn't really require any decision or feedback, ought to go through email. Or if not, at least keep it very short and to the point.
(And, no, the most common excuse "but what if they have questions?" is usually just that: a piss-poor excuse. "Yes, the company still exists, we're great, the marketting guys sold some other team's product, etc." Well, it's all great news, but exactly what questions is someone supposed to ask? The only you'll actually get is from idiots who think they get bad marks from the boss if they don't ask something. Anything. Just to show they were there.)
E.g., lack of feedback or lack of sense of any purpose. It may seem like it's conflicting with the previous point, but it's not. Feedback doesn't equal endless pointless meetings.
4. Mis-management.
E.g., poor resource use, when someone actually has nothing to do for a month.
E.g., poor team management where people are left to basically fend for themselves and coax each other into adding this one more function or fixing this bug. Some will take this as a good opportunity to not do anything, not even fix their own bugs, such as the Wally avatar I have for a co-worker. Some will get disheartened at having to spend hours coaxing Wally to even fix a bug, and delay that as much as possible out of self-preservation. Some things will deadlock because of conflicting requests and no management to decide which way to go. (True case: "Yes, I need this new parameter" from one co-worker, and 3 others going "No way mate, I'm not changing to a new and incompatible version of your EJB's client right before a release".)
E.g., the most harm that management can do is sapping morale, or letting people sap each others.
For example if it degenerates into a chaotic situation where everyone comes to work and finds that code that they spent 12 hours debugging yesterday doesn't work today, because someone changed something. And you don't even know who, what or where. It's not only a waste of time as such (and the boss may just see this as "these procrastinators aren't making any progress again"), it saps morale too.
5. Morale again: that feeling of "why should I bother any more?" Maybe it deserves its own point after all.
E.g., feedback from the team bei
A polar bear is a cartesian bear after a coordinate transform.
If you had the bad luck to have been thought by lazy sociopaths you have our deepest simpathy but not necessarliy our support in your derogatory blanket generalizations.
Many of the advances in computer sciences that have made life easier for many people in the IT industries come from people in the academic field.
Obviously you don't understand the demands of a teaching position. You have to prepare tha class, grade the students, keep up to date in the cutting edge and then deal with complete idiots that believe they know it all because have a bit of working experience when in reality lack the most fundamental foundations in computing.
But of course since you seem to be such a brilliant star in the IT firmament, surely have a better solution to the time tested teaching system followed in most places around the world which will free the brightest minds in our classrooms from the tyranny of the teachers.
Why should the young listen respectfully, why age, experience and insight should be held on any respect whatsoever if the youngs minds will lead ud to an era of prosperity, abundancy and progress. Like they did during the dot com era for example.
IANAL but write like a drunk one.