4 ms·

Revisiting The Facts and Fallacies of Software Engineering

15 points by nreece 19y ago

dhimes 19y ago
I prefer how-to books to what-is books. Tell me the best practices so that I don't waste time and effort.
m0nty 19y ago
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 19y ago
  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 19y ago
    Steve McConnell just wrote something about this: http://news.ycombinator.com/item?id=147916 http://news.ycombinator.com/item?id=147916
edw519 19y ago
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 19y ago
  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 19y ago
    "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 19y ago
      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).
  - edw519 19y ago
    Wow, wallflower, you got me to reply twice to the same post. Good job! "you can't impact/maximize one of those three without affecting the others" As soon as someone finishes saying "can't", I start looking for the business opportunity.
    - dgabriel 19y ago
andrewl 19y ago
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.

15 points by nreece 19y ago

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

m0nty 19y ago

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 19y ago
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 19y ago
  Steve McConnell just wrote something about this: http://news.ycombinator.com/item?id=147916 http://news.ycombinator.com/item?id=147916

edw519 19y ago

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 19y ago
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 19y ago
  "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 19y ago
    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).
- edw519 19y ago
  Wow, wallflower, you got me to reply twice to the same post. Good job! "you can't impact/maximize one of those three without affecting the others" As soon as someone finishes saying "can't", I start looking for the business opportunity.
  - dgabriel 19y ago

andrewl 19y ago

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.