Rodrigo Guerreiro

Facts and Fallacies of Software Engineering

When I read this post from Jeff Atwood suddenly came to mind the presentation (video) that Bruno and Tiago gave at TechDays 2005. Basically, the points that they mentioned there are the same that Jeff described in his post (based on the book Facts and Fallacies of Software Engineering, by Robert L. Glass). I'll put them here for everyone read and meditate it.

People

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

Tools and Techniques

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

Estimation

1. One of the two most common causes of runaway projects is poor estimation.
2. Software estimation usually occurs at the wrong time.
3. Software estimation is usually done by the wrong people.
4. Software estimates are rarely corrected as the project proceeds.
5. It is not surprising that software estimates are bad. But we live and die by them anyway!
6. There is a disconnect between software management and their programmers.
7. The answer to a feasability study is almost always "yes".

Reuse

1. Reuse-in-the-small is a solved problem.
2. Reuse-in-the-large remains a mostly unsolved problem.
3. Reuse-in-the-large works best in families of related systems.
4. Reuseable components are three times as hard to build and should be tried out in three different settings.
5. Modification of reused code is particularly error-prone.
6. Design pattern reuse is one solution to the problems of code reuse.

Requirements

1. One of the two most common causes of runaway projects is unstable requirements.
2. Requirements errors are the most expensive to fix during production.
3. Missing requirements are the hardest requirements errors to correct.

Design

1. Explicit requirements 'explode' as implicit requirements for a solution evolve.
2. There is seldom one best design solution to a software problem.
3. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.

Coding

1. Designer 'primitives' rarely match programmer 'primitives'.
2. COBOL is a very bad language, but all the others are so much worse.

Error removal

1. Error removal is the most time-consuming phase of the lifecycle.

Testing

1. Software is usually tested at best to the 55 to 60 percent coverage level.
2. 100 percent test coverage is still far from enough.
3. Test tools are essential, but rarely used.
4. Test automation rarely is. Most testing activities cannot be automated.
5. Programmer-created, built-in debug code is an important supplement to testing tools.

Reviews and Inspections

1. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
2. Rigorous inspections should not replace testing.
3. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
4. Reviews are both technical and sociological, and both factors must be accommodated.

Maintenance

1. Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.
2. Enhancements represent roughly 60 percent of maintenance costs.
3. Maintenance is a solution-- not a problem.
4. Understanding the existing product is the most difficult maintenance task.
5. Better methods lead to more maintenance, not less.

Quality

1. Quality is a collection of attributes.
2. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.

Reliability

1. There are errors that most programmers tend to make.
2. Errors tend to cluster.
3. There is no single best approach to software error removal.
4. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.

Efficiency

1. Efficiency stems more from good design than good coding.
2. High-order language code can be about 90 percent as efficient as comparable assembler code.
3. There are tradeoffs between optimizing for time and optimizing for space.

Research

1. Many researchers advocate rather than investigate.

Unfortunately most of software developers and software companies don't consider this, at least in Portugal. I say no more!

Until next time ;)

Print | posted on Tuesday, April 08, 2008 9:08 AM