Facts and Fallacies of Software Engineering (Rob Glass) CSE301 University of Sunderland Discussed by Harry R. Erwin, PhD

Prime Citation Robert L. Glass, 2003, Facts and Fallacies of Software Engineering, Addison-Wesley. Glass is very good, he cites his sources, and they are usually peer-reviewed. What you should get from this lecture is information to help you think critically about the software development process.

Management Facts People Tools and Methodologies Estimation Reuse Complexity

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.

Tools and Methodologies Hype is the plague on the house of software. New tools and techniques cause an initial loss of productivity and quality. Software developers seldom really use tools.

Estimation A common cause of runaway projects is poor estimation. Software estimation is usually done at the wrong time and by the wrong people. Software estimates are rarely corrected. You will live and die by software estimates, despite their badness. There is a disconnect between management and programmers. Feasibility studies almost always answer ‘yes’.

Reuse Reuse in the small is well-solved. Reuse in the large is mostly unsolved. Reuse in the large works best for families of related systems. Reusable components cost three times as much to build and should be tested in at least three settings. Modification of reused code is particularly error- prone. Design pattern reuse is a good idea.

Complexity For each 25% increase in problem complexity, there is a 100% increase in solution complexity. 80% of software work is intellectual. Some is creative. Little is clerical.

Life Cycle Facts Requirements Design Coding Error Removal Testing Reviews and Inspections Maintenance

Requirements The second common cause of runaway projects is requirements instability. Requirements errors are most expensive to fix during production. Missing requirements are very hard to fix.

Design Explicit requirements ‘explode’ as the design evolves. Multiple design solutions usually exist. Design is complex and iterative. Initial designs are usually wrong and certainly non-optimal.

Coding Designer ‘primitives’ rarely match programmer ‘primitives’. COBOL is bad. All the other languages for business applications are much worse.

Error Removal The most time-consuming phase of the software life cycle. (Barry Boehm indicates that pair programming takes about 10-20% more total effort for a given module, but results in 60% less errors in the delivered code. This is the first time we’ve seen a real silver bullet for the problem of quality.)

Testing Aim for 55-60% branch coverage. 100% branch coverage is far from enough. Test tools are essential. Test automation rarely is. Most tests cannot be automated. Your debug code is an important supplement to testing tools.

Reviews and Inspections Rigorous inspections can catch 90% of the errors. Rigorous inspections should not replace testing. Postdelivery reviews are important and seldom performed. Reviews are both technical and sociological. Accommodate both.

Maintenance Maintenance is the most important life cycle phase with 40-80% of the cost. Enhancements make up about 60% of the maintenance cost. Maintenance is a solution, not a problem. Understanding the existing product is the most difficult maintenance task. Better methods lead to more maintenance.

Quality Facts Quality Reliability Efficiency

Quality Quality is a number of attributes. –Portability, reliability, efficiency, usability, testability, understandability, and modifiability. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.

Reliability There are common errors that most programmers make. Errors tend to cluster. There is no single best approach to software error removal. There are always residual errors. The goal is to minimize or eliminate severe errors.

Efficiency Efficiency stems from good design, not good coding. High-order language code can be about 90% as efficient at hand-coded assembly language code. Size and time optimization trade off.

Research Many researchers advocate rather than investigate.

Fallacies Management Life Cycle Education

Management Fallacies “You can’t manage what you can’t measure.” “You can manage quality into a software product.” “Programming can and should be egoless.” “Tools and techniques: one size fits all.” “Software needs more methodologies.” “To estimate cost and schedule, first estimate lines of code.”

Life Cycle Fallacies “Random test input is a good way to optimize testing.” “Given enough eyeballs, all bugs are shallow.” “To predict future costs, look at past cost data.”

Education Fallacy “You teach people how to program by showing them how to write programs.”