Facts and Fallacies of Software Engineering
Facts of Software Engineering
People
People
- The most important factor in software work is the quality of the programmers.
- The best programmers are up to 28 times better than the worst programmers.
- Adding people to a late project makes it later.
- The working environment has a profound impact on productivity and quality.
- Hype (about tools and technology) is a plague on the house of software.
- New tools and techniques cause an initial loss of productivity / quality.
- Software developers talk a lot about tools, but seldom use them.
- One of the two most common causes of runaway projects is poor estimation.
- Software estimation usually occurs at the wrong time.
- Software estimation is usually done by the wrong people.
- Software estimates are rarely corrected as the project proceeds.
- It is not surprising that software estimates are bad. But we live and die by them anyway!
- There is a disconnect between software management and their programmers.
- The answer to a feasability study is almost always "yes".
- Reuse-in-the-small is a solved problem.
- Reuse-in-the-large remains a mostly unsolved problem.
- Reuse-in-the-large works best in families of related systems.
- Reusable components are three times as hard to build and should be tried out in three different settings.
- Modification of reused code is particularly error-prone.
- Design pattern reuse is one solution to the problems of code reuse
-
For every 25 percent increase in problem complexity, There is a hundred percent increase in solution complexity.
-
Eighty percent software work is intellectual. A fair amount it is creative. little of it is clerical
Requirements
- One of the two most common causes of runaway projects is unstable requirements.
- Requirements errors are the most expensive to fix during production.
- Missing requirements are the hardest requirements errors to correct.
- Explicit requirements 'explode' as implicit requirements for a solution evolve.
- There is seldom one best design solution to a software problem.
- Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.
- Designer 'primitives' rarely match programmer 'primitives'.
- COBOL is a very bad language, but all the others are so much worse.
- Error removal is the most time-consuming phase of the life-cycle.
- Software is usually tested at best to the 55 to 60 percent coverage level.
- 100 percent test coverage is still far from enough.
- Test tools are essential, but rarely used.
- Test automation rarely is. Most testing activities cannot be automated.
- Programmer-created, built-in debug code is an important supplement to testing tools.
- Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
- Rigorous inspections should not replace testing.
- Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
- Reviews are both technical and sociological, and both factors must be accommodated.
- Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software life-cycle phase.
- Enhancements represent roughly 60 percent of maintenance costs.
- Maintenance is a solution-- not a problem.
- Understanding the existing product is the most difficult maintenance task.
- Better methods lead to more maintenance, not less.
- Quality is a collection of attributes.
- Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.
- There are errors that most programmers tend to make.
- Errors tend to cluster.
- There is no single best approach to software error removal.
- Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
- Efficiency stems more from good design than good coding.
- High-order language code can be about 90 percent as efficient as comparable assembler code.
- There are trade offs between optimizing for time and optimizing for space.
- Many researchers advocate rather than investigate.
- You can't manage what you can't measure.
- You can manage quality into a software product.
- Programming can and should be ego less.
- Tools and techniques: one size fits all.
- Software needs more methodologies.
- To estimate cost and schedule, first estimate lines of code.
- Random test input is a good way to optimize testing.
- "Given enough eyeballs, all bugs are shallow".
- The way to predict future maintenance costs and to make product replacement decisions is to look at past cost data.
- You teach people how to program by showing them how to write programs.
Comments
Post a Comment