Facts and Fallacies of Software Engineering

Aleksandr Shitik

I write my own posts and books, and review movies and books. Expert in cosmology and astronomy, IT, productivity, and planning.

Robert L. Glass

Genres: Programming

Year of publication: 2008

Year of reading: 2020

My rating: Highest

Number of reads: 1

Total pages: 233

Summary (pages): 0

Original language of publication: English

Translations to other languages: Russian, Chinese

General Information

This is a 2008 book consisting of 55 facts and 10 myths about developers and programming in general. All materials are divided into specific groups, such as management, development, and others.

It’s worth noting right away that almost all the topics and questions discussed by the author are highly debatable, and different readers may have strongly differing opinions. To save time and space, I’m not going to describe my own views on each point. Here I’ll simply list all the facts and myths, and give an overall evaluation of the book at the end. Each fact or myth is presented in the format of a medium-length article, so if you're interested, you can choose to read specific topics rather than the entire book. Before listing all the facts and myths, I’ll also point out that the author follows a clear structure when presenting material:

• First, he discusses the fact or myth itself.
• Then he outlines the arguments and debates around it.
• Finally, he provides sources of information related to the topic.

Programming Facts

Human Factor

1. The most important factor in software development is not the methods and tools used by programmers, but the programmers themselves.
2. According to research on individual differences, the best programmers outperform the worst ones by up to 28 times. Considering their compensation is never proportional, the best programmer is the most valuable asset in the software industry.
3. If a project is behind schedule, adding more manpower will delay it even further.
4. Working conditions greatly influence productivity and the quality of results.
5. The hype surrounding tools and methodologies is a plague on the software industry. Most improvements in tools and methods lead to a 5–35% increase in productivity and quality. However, many of these improvements are touted as giving "an order of magnitude" advantage.
6. Learning a new tool or method initially decreases productivity and product quality. The benefits only come after the learning curve has been overcome. Thus, introducing new tools and methods makes sense only if a) their actual value is evident, and b) one has the patience to wait for the payoff.
7. Developers talk a lot about tools. They try many, acquire them in abundance, but rarely use them effectively.
8. One of the most common causes of project mismanagement is poor estimation. (The second reason is discussed in Fact 23.)
9. Most project estimates in software are made early in the lifecycle. This doesn't concern us until we realize the estimates are made before the requirements are defined, and thus before the task is understood. Therefore, the timing of the estimates is usually inappropriate.
10. Most project estimates in software are made by top managers or marketing staff—not by those who will develop the software, nor by their supervisors. So the wrong people are doing the estimating.
11. Software project estimates are rarely refined later. In other words, estimates made by the wrong people at the wrong time typically remain uncorrected.
12. Since estimates are so often incorrect, there's little reason to worry about software projects not finishing on time. Yet everyone worries anyway.
13. There is a lack of communication between managers and programmers. One study of a project considered a failure by management (due to unmet estimates) found that the developers viewed it as the most successful project they’d ever worked on.
14. Feasibility analysis of a project almost always gives a "yes" answer.
15. Small-scale reuse (via subroutine libraries) has been around for almost 50 years and is well-understood.
16. Large-scale reuse (via components) remains largely unsolved, though it’s widely agreed to be important.
17. Successful large-scale reuse is most effective within families of related systems, and thus depends on the application domain. This narrows its potential applicability.
18. There are two "rules of three" in reuse: a) reusable components take three times the effort of single-use components, and b) a reusable component must be tested in three different applications before it's general enough to be included in a component library.
19. Modifying reused code is highly error-prone. If more than 20–25% of a component needs to be changed, it's better to rewrite it from scratch.
20. Reusing design patterns addresses many issues that arise with code reuse.
21. Increasing task complexity by 25% increases software solution complexity by 100%. This is a fact of life—not something we can easily change (though we should always aim to minimize complexity).
22. 80% of software development effort is intellectual. A large portion of this is creative work. Only a small part is technical.

Requirements

23. One of the two most common causes of project mismanagement is changing requirements. (The other is discussed in Fact 8.)
24. Fixing requirement errors is most expensive when found in production, and cheapest when caught early in development.
25. Missing requirements are the hardest type of error to fix.

Design

26. As we move from initial requirements to architecture, we are overwhelmed by a flood of "derived requirements" (requirements tied to specific design decisions) caused by process complexity. This list is often 50 times longer than the original.
27. The best design solution to a programming problem is rarely the only one.
28. Design is a complex, iterative process. The initial design solution is likely wrong, and definitely not optimal.

Coding

29. Programmers move from design to coding when the task is broken down into "primitives" understood by the designer. If the coder is not the same person as the designer, the designer’s primitives may not match those of the coder—leading to trouble.
30. COBOL is a very bad language, but all others (for business data processing) are much worse.
31. The error correction phase is the most labor-intensive part of the software lifecycle.

Testing

32. It turns out that in software which a typical programmer assumes is thoroughly tested, only about 55–60% of logical paths are actually verified. Using automated tools such as coverage analyzers can raise this to approximately 85–90%. Testing 100% of logical paths is practically impossible.
33. Even if 100% test coverage were achievable, it wouldn't be sufficient as a testing adequacy criterion. Around 35% of software defects are due to missed logical paths, and another 40% stem from unique combinations of logical paths. These cannot be identified with 100% test coverage.
34. Without instrumentation tools, it is nearly impossible to effectively eliminate errors. Debuggers are widely used—unlike other tools, such as coverage analyzers.
35. Tests are rarely automated. That is, certain testing processes can and should be automated. But a significant portion of testing work cannot be automated.
36. An important addition to testing tools is programmer-written built-in debug code, preferably included in the object code depending on compilation directives.
37. Thorough inspections can eliminate up to 90% of errors from a software product before the first baseline test is run.
38. Thorough inspections offer many benefits but cannot replace testing.
39. It is widely acknowledged that post-mortem reviews (also called retrospectives) are important both from the user's perspective and for process improvement. However, in most organizations, such reviews are not conducted.
40. Inspections involve not only technical factors but also social ones. Focusing too much on one at the expense of the other is a direct path to disaster.
41. Maintenance typically accounts for 40 to 80% (on average 60%) of the total software cost. Therefore, this phase of the lifecycle may be the most important.
42. About 60% of maintenance costs go to code improvement and about 17% to bug fixing. Thus, software maintenance and support mostly involve adding new features rather than fixing issues.
43. Maintenance is a solution, not a problem.
44. When comparing software development and maintenance, they are mostly similar—except for an additional task in maintenance: "learning the maintained product." This task takes about 30% of the total maintenance time and dominates the maintenance effort. Therefore, maintenance is more labor-intensive than development.
45. Improving software development quality leads to more maintenance, not less.

Quality

46. Quality is a combination of properties.
47. Quality is not defined by user satisfaction, meeting client requirements, acceptable cost and delivery time, or reliability.
48. There are certain errors that most programmers are prone to make.
49. Errors tend to cluster.
50. There is no single best approach yet developed for eliminating errors.
51. Errors are inevitable. The goal is to avoid critical ones or minimize them.

Efficiency

52. Efficiency depends more on high-quality application design than on high-quality programming.
53. The efficiency of high-level language code, compiled with appropriate optimization settings, can reach 90% of the efficiency of functionally comparable assembly code. In some complex modern architectures, it can even be higher.
54. There are trade-offs between size optimization and speed optimization. Often improving one will degrade the other.

On Scientific Research

55. Many scientists working in the software industry tend to defend their theories rather than conduct research. As a result: a) the value of some promoted theories is much lower than their advocates believe; b) there is a lack of research aimed at determining the actual value of these theories.

Programming Misconceptions

1. You can't manage what you can't measure.
2. Management can ensure software quality.
3. Programming can and should be impersonal.
4. Tools and technologies are universal.
5. Programming needs more methodologies.
6. To estimate cost and set deadlines, start by counting lines of code.
7. Using random input data is a good way to optimize testing.
8. "All bugs are shallow given enough eyeballs."
9. Knowing the cost of previous maintenance allows predicting future maintenance costs and deciding whether to replace a product.
10. People can be taught to program by showing them how to write code.

Conclusion

Although the book was written back in 2008, I still recommend it to those studying programming. One downside that immediately stands out is that it's difficult to confirm or refute the percentages and figures the author cites for certain facts. Also, a few facts have become outdated. That said, the overwhelming majority of the material remains relevant and will be useful not only for developers but also for managers.