He mentions that the fallacies don't stand up to analysis (which is what you'd expect) but I'd encourage you to resist the head-nod temptation when looking through the list of contents, which we're encouraged to accept as "zen koan-like". For example:
"The best programmers are up to 28 times better than the worst programmers."
I'm immediately suspicious of the spurious accuracy presented and wondering why it's not 30 or 25. And it means not much in practice: the best person in any profession will be orders of magnitude better than the worst, if only because the worst can be very, very bad indeed.
I always find those numbers odd, since it implies that all programmers create some value. Bad programmers not only don't produce much, they introduce bugs that others need to fix and they need lots of help, hand-holding, and management effort, which draws down the productivity of others. 28 times better than a negative number isn't good at all!
What an interesting reference! Thank you, Jeff. I'm surprised I never heard of it. It seems so full of common sense that I think it's definitely worth a read.
I especially liked these two:
25. Missing requirements are the hardest requirements errors to correct.
42. Enhancements represent roughly 60 percent of maintenance costs.
If an "enhancement" is the result of "missing requirements", then is it really an enhancement at all? My experience is that 90% of "maintenance" was the direct result of poor or incomplete analysis. Let's not forget that "software engineering" includes all phases, not just development.
During some crunch times, I've told our business analysts that it's not a bug if they have to write a requirement for it (the bug) :)
And, in an ideal world, requirements would be stable before coding starts. We make the best of what we can work with. Cost, quality, functionality - the classic triangle - you can't impact/maximize one of those three without affecting the others
"in an ideal world, requirements would be stable before coding starts"
It is and they are.
I think the common misconception is that requirements change during the project. My experience is that this is a rarity
What really happens is that OUR VIEW of the requirements changes during the project. The business rules didn't just suddenly change because we are building something. We NEVER NAILED THEM DOWN in the first place. This isn't hard to comprehend; analysis is a lost art and probably the most fragile link in the SDLC chain.
"What do you mean, when we file the record, a traveler should print out next to the supervisor's desk? Who told you that?"
"Joe did."
"What did Mary say?"
"I don't know. I didn't ask her."
"Ask her. Once you get her answer, change the specs."
(A silly little example, but is I had a nickel for every time that happened...)
In my experience, this depends a lot on the project. Often, with new ideas, new uses will come up once the 'opinion leaders' get their hands on something real. Then, the requirements, in fact, do change (if you're smart).
If you think you can solve the classic "Good/Fast/Cheap - pick two" conundrum in a way that is ethical and sustainable, then go for it. That's the grail in more fields than just software.
I totally see what you mean, and technology has brought the formerly impossible into the reach of millions.
Technically, however, the absolute cheapest way to get there is to borrow a bike and some camping gear and start pedaling, and the absolute fastest way is to hop into your own private jet waiting in your backyard. The first is waaaay too time-consuming for most people to consider reasonable, and the latter is too expensive for most people to attain. Commercial air travel is the best compromise between the two.
The problem with most clients is that they want a private jet at borrowed bicycle prices.
"The best programmers are up to 28 times better than the worst programmers."
I'm immediately suspicious of the spurious accuracy presented and wondering why it's not 30 or 25. And it means not much in practice: the best person in any profession will be orders of magnitude better than the worst, if only because the worst can be very, very bad indeed.