Facts and Fallacies of Software Engineering (Paperback)

Fact 1. The most important factor in software work is the quality of the programmers.
Fact 2. The best programmers are up to 28 times better than the worst programmers.
Fact 3. Adding people to a late project makes it later.
Fact 4. The working environment has a profound impact on productivity and quality.

Fact 5. Hype (about tools and techniques) is the plague on the house of software.
Fact 6. New tools/techniques cause an initial loss of productivity/quality.
Fact 7. Software developers talk a lot about tools, but seldom use them.

Fact 8. One of the two most common causes of runaway projects is poor estimation.
Fact 9. Software estimation usually occurs at the wrong time.
Fact 10. Software estimation is usually done by the wrong people.
Fact 11. Software estimates are rarely corrected as the project proceeds.
Fact 12. It is not surprising that software estimates are bad. But we live and die by them anyway!
Fact 13. There is a disconnect between software management and their programmers.
Fact 14. The answer to a feasibility study is almost always “yes” .

Fact 15. Reuse-in-the-small is a well-solved problem.
Fact 16. Reuse-in-the-large remains a mostly unsolved problem.
Fact 17. Reuse-in-the-large works best for families of related systems.
Fact 18. Reusable components are three times as hard to build, and should be tried out in three settings.
Fact 19. Modification of reused code is particularly error-prone.
Fact 20. Design pattern reuse is one solution to the problems of code reuse.

Fact 21. For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
Fact 22. Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.

Fact 23. One of the two most common causes of runaway projects is unstable requirements.
Fact 24. Requirements errors are the most expensive to fix during production.
Fact 25. Missing requirements are the hardest requirements errors to correct.

Fact 26. Explicit requirements “explode” as implicit (design) requirements for a solution evolve.
Fact 27. There is seldom one best design solution to a software problem.
Fact 28. Design is a complex, iterative process. Initial design solutions are usually wrong, and certainly not optimal.

Fact 29. Designer “primitives” (solutions they can readily code) rarely match programmer “primitives” .
Fact 30. COBOL is a very bad language, but all the others (for business applications) are so much worse.

Fact 31. Error-removal is the most time-consuming phase of the life cycle.

Fact 32. Software is usually tested at best at the 55-60 percent (branch) coverage level.
Fact 33. 100 percent coverage is still far from enough.
Fact 34. Test tools are essential, but many are rarely used.
Fact 35. Test automation rarely is. Most testing activities cannot be automated.
Fact 36. Programmer-created, built-in, debug code is an important supplement to testing tools.

Fact 37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
Fact 38. But rigorous inspections should not replace testing.
Fact 39. Post-delivery reviews (some call them “retrospectives” ) are important, and seldom performed.
Fact 40. Reviews are both technical and sociological, and both factors must be accommodated.

Fact 41. Maintenance typically consumes 40-80 percent of software costs. It is probably the most important life cycle phase of software.
Fact 42. Enhancements represent roughly 60 percent of maintenance costs.
Fact 43. Maintenance is a solution, not a problem.
Fact 44. Understanding the existing product is the most difficult task of maintenance.
Fact 45. Better methods lead to MORE maintenance, not less.

Fact 46. Quality IS: a collection of attributes.
Fact 47. Quality is NOT: user satisfaction, meeting requirements, achieving cost/schedule, or reliability.

 

事實1. 軟體工作中最重要的因素是程式設計師的品質。
事實2. 最好的程式設計師比最差的程式設計師優秀28倍。
事實3. 在延遲的專案中增加人員只會使其更加延遲。
事實4. 工作環境對生產力和品質有深遠影響。

事實5. 對於工具和技術的炒作是軟體領域的災難。
事實6. 新的工具/技術會導致初始的生產力/品質損失。
事實7. 軟體開發人員常常談論工具，但很少使用它們。

事實8. 專案失控的兩個最常見原因之一是估算不足。
事實9. 軟體估算通常在錯誤的時間進行。
事實10. 軟體估算通常由錯誤的人進行。
事實11. 專案進行過程中很少修正軟體估算。
事實12. 軟體估算不準確並不令人驚訝。但我們仍然依賴它們生死相隨！
事實13. 軟體管理人員與他們的程式設計師之間存在脫節。
事實14. 可行性研究的答案幾乎總是“是”。

事實15. 小規模重複使用是一個解決得很好的問題。
事實16. 大規模重複使用仍然是一個基本未解決的問題。
事實17. 大規模重複使用對於相關系統家族效果最好。
事實18. 可重複使用的元件的建立難度是原來的三倍，應該在三個環境中試用。
事實19. 修改重複使用的程式碼特別容易出錯。
事實20. 設計模式重複使用是解決程式碼重複使用問題的一種方法。

事實21. 問題複雜度每增加25％，解決方案複雜度就增加100％。
事實22. 軟體工作中80％是智力工作，其中相當一部分是創造性的，很少是文書工作。

事實23. 專案失控的兩個最常見原因之一是不穩定的需求。
事實24. 在生產過程中修正需求錯誤是最昂貴的。
事實25. 遺漏的需求是最難修正的需求錯誤。

事實26. 明確的需求在解決方案演進過程中會變成隱含的（設計）需求。
事實27. 軟體問題很少只有一個最佳設計解決方案。
事實28. 設計是一個複雜的迭代過程。初始設計解決方案通常是錯誤的，並且絕對不是最佳的。

事實29. 設計師的“基本元素”（他們可以輕鬆編碼的解決方案）很少與程式設計師的“基本元素”相匹配。
事實30. COBOL是一種非常糟糕的語言，但其他所有（用於商業應用）語言都更糟糕。

事實31. 錯誤修復是生命週期中最耗時的階段。

事實32. 軟體通常只在55-60％（分支）覆蓋率下進行測試。
事實33. 100％覆蓋率仍然遠遠不夠。
事實34. 測試工具是必不可少的，但很多時候很少使用。
事實35. 測試自動化很少存在。大多數測試活動無法自動化。
```