Facts and Fallacies of Software Development
Introduction
There is an old adage: those who do not remember history, are doomed to spend eternity studying it in high school because they keep failing the tests, which means they keep failing the class, which means they keep taking the class.
So, I try to learn what I can from past experience. Being a young pup in the software industry, I mostly get to learn from the mistakes of other people by reading their books, articles, or blogs. Which is why I am an avid reader of software books, articles, or blogs, especially those that have to do with techniques and methodologies others have found successful. (Or maybe I read too much because I am trying to escape from reality? Suggestions welcome.) I, for one, do not want to spend eternity in my high school history class.
So it was with exuberance that I picked up and read Robert L. Glass’s Facts and Fallacies of Software Engineering. In it, Glass outlines 55 facts and 10 fallacies of software development. He argues that there are so many things about software development that have already been studied, discovered, and solved, but that the industry continues to fall into the same traps.
Although I would love to list all his facts and fallacies, but I will not. That would ruin the fun. But I will comment on a few that made me think.
Fact 2. The best programmers are 28 times better than the worst programmers.
I agree with this fact (because I have heard it repeated so many times), though I have not experienced it in the field. I have spent almost my entire professional career on a two-man team (and the second member has never changed) and we produce about the same. Glass makes the point that nobody has come up with a good way of finding out who these super-programmers are:
We have struggled over the years with programmer aptitude tests and certified data processor exams and the ACM self-assessment programs, and the bottom line, after a lot of blood and sweat and perhaps even tears were spent on them, was that the correlation between test scores and on the job performance is nil. (You think that was disappointing? We also learned, about that time, that computer science class grades and on-the-job performance correlated abysmally also.)
So now I have a question burning in my head: how do I know or find out where I am on the scale? I would like to think (as all developers would) that I am one of the better ones, but who knows?
Fact 21. For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
This is a fact that I have seen and experienced, but it never really consciously entered into my head. As soon as I saw it in print, I thought back onto the software I wrote, shook my head, and thought “He’s right!”
This supports Steve McConnell, who, in his book Code Complete, said that the first goal of software is to manage complexity. As G.I. Joe says, “Knowing is half the battle.” Knowing that your software is going to get complex so quickly helps you to write code that is easier to understand and maintain, thus managing complexity.
Fact 30. COBOL is a very bad language, but all others (for business applications) are so much worse.
Yes. My jaw did the same thing when I read that. All I have ever heard about COBOL are jokes and comments of derision. Now, on top of trying to learn Ruby and Ruby on Rails, I have to go learn COBOL to see what Glass is talking about, because I certainly don’t buy it.
Fact 37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
I had read this before, in McConnell’s Code Complete, and it was good to see it again here. Unfortunately, I work for a company that performs zero code inspections. I have requested them in the past, but nothing has happened. I think my next book might be Peer Reviews in Software–A Practical Guide, by Karl Wiegers, so that I can start to organize these myself. (McConnell also recommended a book in Code Complete, but my copy is at work, so I can’t look it up.)
I, for one, would love to have other people looking at my code. I am not stupid enough to think that I have the corner market on coding, library knowledge, etc. There are people smarter than me, and I want to learn from them. Code inspections seem the best environment for them.
Plus, code inspections help transfer (some) knowledge, which most organizations crave.
Conclusion
And I could go on and on. These are just some of the ones that caught my attention and made me think a little bit (no small feat). He has seven facts on estimation alone, which I would like to go into, but will leave that for another day.
Recommendation
