Facts and Fallacies of Software Engineering (Rob Glass)

1
Facts and Fallacies of Software Engineering (Rob
Glass)

• CSE301
• University of Sunderland
• Discussed by Harry R. Erwin, PhD

2
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.

3
Management Facts

• People
• Tools and Methodologies
• Estimation
• Reuse
• Complexity

4
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.

5
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.

6
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.

7
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.

8
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.

9
Life Cycle Facts

• Requirements
• Design
• Coding
• Error Removal
• Testing
• Reviews and Inspections
• Maintenance

10
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.

11
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.

12
Coding

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

13
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 weve seen
  a real silver bullet for the problem of quality.)

14
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.

15
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.

16
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.

17
Quality Facts

• Quality
• Reliability
• Efficiency

18
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.

19
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.

20
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.

21
Research

• Many researchers advocate rather than investigate.

22
Fallacies

• Management
• Life Cycle
• Education

23
Management Fallacies

• You cant manage what you cant 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.

24
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.

25
Education Fallacy

• You teach people how to program by showing them
  how to write programs.