
Revisiting The Facts and Fallacies of Software Engineering - nreece
http://www.codinghorror.com/blog/archives/001083.html
======
m0nty
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.

~~~
pchristensen
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!

~~~
pchristensen
Steve McConnell just wrote something about this:

<http://news.ycombinator.com/item?id=147916>

------
andrewl
I found these two rather odd:

7\. Software developers talk a lot about tools, but seldom use them.

30\. COBOL is a very bad language, but all the others are so much worse.

Number 7 just doesn't match my experience. But I am an N of 1. I don't know
what to make of 30 at all.

And this one made me think the book was rather old (which doesn't mean out of
date necessarily):

53\. High-order language code can be about 90 percent as efficient as
comparable assembler code.

I just wonder what he means by higher-order? In this context, probably C.

------
dhimes
I prefer how-to books to what-is books. Tell me the best practices so that I
don't waste time and effort.

------
edw519
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.

~~~
wallflower
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

~~~
edw519
"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...)

~~~
dhimes
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).

