Facts and Fallacies of Software Engineering

a.k.a. “Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering”
Very important book with timeless facts about software engineering. By Robert L. Glass, professional software engineer since 1954 (think about it).
If you haven’ t read it, I won’t employ you. 😉


Randomy picking out a few:
[list]
[*]Fact 19: If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.
[*]Fact 21: For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That’s not a condition to try to change (even though reducing complexity is always a desirable thing to do); that’s just the way it is.
[*]Fact 28: Design is a complex, iterative process. The initial design solution will likely be wrong and certainly not optimal.
[/list]
And, one of my favorites:
[quote]”How did you learn to program? I’ll bet it was at some sort of academic class, at which the teacher or professor showed you the rules for a programming language and turned you loose on writing some code. And if you learned to program in more than one language, I’ll bet it was the same. You read or were taught about this new language, and off you went, writing code in it.
That’s so much the norm in learning to program that you probably don’t see anything wrong with that. But there is. Big time.
The problem is this: In learning any other language, the first thing we do is learn to read it. You get a copy of Dick and Jane or War and Peace or something somewhere in between, and you read. You don’t expect to write your own version of Dick and Jane or War and Peace until you’ve read lots of other examples of what skilled writers have written. (Believe me, writing Dick and Jane does require skill! You have to write using a vocabulary that’s age- and skill-appropriate for your readers.)
So how did we in the software field get stuck on this wrong track, the track of teaching writing before reading? I’m not really sure. But stuck on it, we are. I know of no academic institution, or even any textbook, that takes a reading-before-writing approach. In fact, the standard curricula for the various computing fields—computer science, software engineering, information systems—all include courses in writing programs and none in reading them.”
[/quote]
Please, someone, build a good shiny Web 2.0 based collaboration platform where we can learn from, discuss and refactor each others code. Something like a [url=http://www.hanselman.com/blog/IntroducingBabySmashAWPFExperiment.aspx]generic BabySmash[/url] platform.
[quote]INTERVIEWER: Is studying computer science the best way to prepare to be a programmer?
BILL GATES: No, the best way to prepare is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system.
You’ve got to be willing to read other people’s code, then write your own, then have other people review your code.
[/quote]

[list]
[*]Robert L. Glass. Facts and Fallacies of Software Engineering. Addison-Wesley. 2002. 224 pages.
[/list]
For more recommendations on software development related books, check out [url=http://www.librarything.com/catalog.php?view=mo.&shelf=list]my bookshelf at LibraryThing[/url].