Facts and Fallacies of Software Engineering

1
Facts and Fallacies of Software Engineering

• From book by Robert Glass, 2003.

2

• The most important factor in software work is not
  the tools and the techniques used by the
  programmers, but the quality of the programmers.

3

• The best programmers are up to 28 times better
  than the worst programmers. Since their pay is
  never commensurate, they are the best bargains in
  the software field.

4
Brookss Law

• Adding people to a late project makes it later.

5

• The working environment has a profound impact on
  productivity and product quality.
• Interruptions very expensive
• Communication is essential

6
Hype is the plague on the house of software

• Most software tool and technique improvements
  account for a 5 to 35 increase in productivity
  and quality. But at one time or another, most of
  them have been claimed by someone to have order
  of magnitude benefits.

7

• Learning a new tool or technique lowers
  programmer productivity and product quality at
  first. The eventual benefit is gained only when
  this learning curve is overcome.
• Be patient
• Dont try new things when you are in a hurry

8

• Software developers talk a lot about tools. They
  evaluate quite a few, buy a fair number, and use
  practically none.

9
Estimation

• One of the two most important reasons for failure
  of a software project is poor estimation.

10
Estimation occurs at wrong time

• Most estimates are made at the beginning of a
  project, before requirements are defined and thus
  before the problem is understood.

11
Estimation is done by the wron people

• Most software estimates are made either by upper
  management or by marketing, not by the people who
  will build the software or their managers.

12

• Software estimates are rarely adjusted as the
  project proceeds. Thus, those estimates done at
  the wrong time by the wrong people are usually
  not corrected.
• Neither XP nor RUP should have this problem.

13

• Since estimates are so faulty, there is little
  reason to be concerned when software projects do
  not meet estimated targets.
• But people are concerned anyway.

14

• For every 25 increase in problem complexity,
  there is a 100 increase in complexity of the
  software solution.

15

• 80 of software work is intellectual. A fair bit
  is creative. Little is clerical.

16

• One of the two most common causes of failed
  projects is unstable requirements.

17

• Requirements errors are the most expensive to fix
  when found during production but the cheapest to
  fix early in development.

18

• Missing requirements are the hardest requirements
  errors to correct.
• The most persistent errors are errors of ommitted
  logic.

19

• When moving from requirements to design, there is
  an explosion of derived requirements caused by
  the complexity of the solution process. The list
  of these design requirements is often 50 times
  longer than the list of original requirements.

20

• There is seldom one best design solution to a
  software problem.
• Software design is hard!
• There are lots of tradeoffs.
• What seems simple depends on what you know.

21

• Design is a complex, iterative process. The
  initial design solution will likely be wrong and
  certainly not optimal.

22

• Programmers shift from design to coding when the
  problem is decomposed to a level of primitives
  that the designer has mastered. If the coder is
  not the same person as the designer, the
  designers primitives are unlikely to match the
  coders primitives, and trouble will result.

23

• Error removal is the most time-consuming part of
  the life-cycle.
• It is nearly impossible to do a good job of error
  removal without tools. Debuggers are commonly
  used, but others, such as coverage analyzers, are
  not.

24

• Test automation rarely is. That is, certain
  testing processes can and should be automated.
  But there is a lot of the testing process that
  cannot be automated.

25

• Programmer-created build-in debug code,
  preferably optionally included in the object code
  based on compiler parameters, is an important
  supplement to testing tools.

26

• Software that a typical programmer believes to be
  thoroughly tested has often has only about 55 to
  60 of its logic paths executed. Using automated
  support, such as coverage analyzers, can raise
  that roughly to 80 to 90. It is nearly
  impossible to test software on the level of 100
  of its logic paths.

27

• Rigorous inspections can remove up to 90 percent
  of errors from a software product before the
  first test case is run.
• In spite of the benefits of rigorous inspections,
  they cannot and should not replace testing.

28

• Maintenance typically consumes 40 to 80 of
  software costs. Therefore, it is probably the
  most important life cycle phase.
• Enhancement is 60 of software maintenance.
  Error correction is under 20

29

• Maintenance is similar to development except for
  the task of understanding the existing product.
  This task consumes about 30 of the total
  maintenance time.
• 15 Defining and understanding the change.
• 5 Reviewing documentation
• 25 Tracing logic
• 20 Implementing the change
• 30 Testing and debugging
• 5 Updating the documentation

30

• Maintenance is a solution, not a problem.
• Better software engineering leads to more
  maintenance, not less.

31
Next time

• Read The Cathedral and the Bazaar, which is
  about open-source process.
• Read the paper, not the book
• http//www.tuxedo.org/esr/writings/cathedral-baza
  ar/cathedral-bazaar/