The facts and fallacies of software engineering

The facts and fallacies of software engineering
Robert L. Glass.
Fact 1: The most important factor in software development is not the tools and techniques that programmers use, but the quality of the programmers themselves.
Fact 2: Research on "Individual differences" shows that the best programmers are 28 times times more powerful than the worst programmers, and even if they are paid differently, good programmers are still the cheapest labor in the software industry.
Fact 3: (Brook Law) additional staffing for deferred projects will further extend the project.
Fact 4: The working environment has a profound impact on work efficiency and product quality.
Fact 5: Most software tools increase efficiency and quality by only 5%~35%, but there is always a repeat that the increase is in order of magnitude.
Fact 6: In the early days of learning new tools and technologies, programmers ' productivity and product quality will fall, and only after overcoming the learning curve will they be able to get substantial gains.
Fact 7: Software developers say much about tools, evaluate less, buy more, and use less.
Fact 8: One of the two main reasons the project is out of control is a bad budget.
Fact 9: Many estimates are SATCM at the beginning of the software life cycle, and later we realize that it is incorrect to estimate the project before the requirement definition, that is, to understand the problem;
Fact 10: Many software projects are estimated by top managers by marketers, not by people who actually build the software or by their supervisors. Therefore, the person who estimates the software is wrong.
Fact 11: Software estimates are rarely adjusted to project progress. As a result, these estimates are usually the wrong result of the incorrect person at the wrong time.
Fact 12: Because the estimated data is so bad, the estimate should not be considered when the software project is unable to reach the estimated target. But anyway, everyone is thinking about it.
Fact 13: There is a gap between managers and programmers. A survey of a project that does not meet the estimated goals shows that a project that a manager seems to fail, but a technician seems to be the most successful project.
Fact 14: The answer to the feasibility study is almost always feasible.
Fact 15: Small-scale multiplexing (sub-Library) began more than more than 50 years ago, and the problem has been well addressed.
Fact 16: Although everyone believes that large-scale reuse (components) is very important and badly needed, the problem has not yet been fundamentally addressed.
Fact 17: Large-scale multiplexing is best used for related systems, that is, depending on the application area, which limits its application.
Fact 18: There are two "three times-fold laws" about multiplexing: (1) Building reusable components is three times times more difficult than using components. (2) Before you ingest a component to a reuse library and become a generic component, you should try to apply the component in three different applications.
Fact 19: Modifying the reused code is particularly prone to errors. Code that exceeds 20%~25% in one component needs to be modified, then the re-implementation will be more efficient.
Fact 20: Design pattern reuse is a way to solve the problems inherent in code reuse.
Design patterns come from practice, not theory.
Fact 21: The complexity of the problem increases by 25%, and the complexity of the solution increases by 100%. This is not a condition that can be changed (even if people try to reduce complexity), but objectively.
The fact that 22:80% 's software work is an intellectual activity, a considerable proportion of it is creative activity and seldom is clerical work.
Fact 23: One of the two common causes of runaway projects is the need for instability.
Fact 24: The cost of revising demand errors at the time of product completion is the largest, minimizing the cost of revising requirements errors early in the development.
Fact 25: Missing demand is the most difficult requirement to revise.
The most persistent software error is the omission of logic errors, which can escape the software testing process and into the released product. Omission of demand leads to omission of logic.
Fact 26: When it comes to design from demand, because of the complexity of the programming, there will be a lot of derivative requirements (for a particular design scenario). Design requirements are 50 times times the size of the original requirements.
Fact 27: For a software problem, there is usually no single best design scenario.
Fact 28: Design is a complex iterative process, and the initial design may be wrong and certainly not optimal.
Fact 29: From the design to the coding stage, the designer at his own level, has broken the problem into the original language. If the programmer and the designer are not the same person, the original language does not match, there will be problems.
Fact 30:cobol language is a very bad language, but other languages (for business data processing) are just as bad.
Fact 31: Error elimination is the most time-consuming phase in the software life cycle.
Checkout Check out testing test verification and validation validation and confirmation
Fact 32: The normal programmer thinks that the software that has been thoroughly tested only executes the 55%~60% logical path. The above ratios can be increased to 85%~90% using automation tools such as the overlay analyzer. It is almost impossible to test the logical path of the soft 100%.
Demand-driven testing (whether the test meets the requirements)
Structure-driven testing (testing that all components of the built software are running correctly)
Statistical drive testing (random testing determines the time and results of software execution)
Risk-driven testing (testing to determine if the most important risks have been eliminated)
Fact 33: This test is not enough even if the test coverage is likely to reach 100%. About 35% of the errors originate from the absence of a logical path, and 40% of the errors originate from the combination of executing a particular path. It is not possible to achieve 100% coverage.
Fact 34: There is no tool to do the error elimination work. People often use debuggers, and few other tools such as overlay analyzers are used.
Fact 35: There are very few automated tests, which means that some tests can and should be done automatically, but there are many test tasks that cannot be done automatically.
Fact 36: Programmers embed test code in the program, and compile parameters in the target code are important additions to the test tool.
Fact 37: A rigorous review before running the first test case eliminates up to 90% of errors in software products.
Fact 38: Although the review has many advantages, it cannot and should not be a substitute for testing.
Fact 39: Post-mortem review is important for understanding customer satisfaction and improving software processes. But many companies do not conduct post-mortem reviews.
Most people recommend a post-mortem review of software delivery for 3-12 months.
Fact 40: Peer review involves both technical and social issues and ignores any aspect of a serious catastrophe. Fact 41: Maintenance expenses usually account for the 40%~80% of software costs (on average 60%). Therefore, maintenance may be the most important phase of the software daughter's life cycle.
Old hardware is discarded and old software is used every day.
Fact 42: Enhancements account for approximately 60% of the cost of software maintenance, and error corrections account for only 17%, so the subject of software maintenance is to add new functionality to the old software rather than correcting the error.
Fact 43: Maintenance is a solution, not a problem.
Fact 44: Comparing the work in software development and software maintenance, in addition to maintaining the "understanding of existing products" work, other work is the same. This work takes up about 30% of the maintenance time and is the main maintenance activity. So it can be said that maintenance is more difficult than development.
Fact 45: Better software process development leads to more rather than less maintenance.
Fact 46: Quality is a set of properties.
Reliability refers to the SOFTWARE PRODUCT to meet the expected requirements, trustworthy.
Ergonomics (usability) software is easy to use and comfortable.
Easy-to-understand and ease-of-maintenance
Efficiency refers to the economy of software products in the running time and space consumption. (Some applications should be in the first place)
Testability
Portability refers to software products that are easy to migrate between different platforms.
Fact 47: Software quality is not user satisfaction, satisfying demand, meeting cost and schedule, or reliability.
Fact 48: Most programmers make certain mistakes.
N-version, fault-tolerant programming fault-tolerant programming
Fact 49: Errors are usually clustered together.
Fact 50: There is no single best way to eliminate software errors.
Fact 51: There will always be some remaining mistakes. Our goal is to eliminate or reduce the severity of the error.
Fact 52: Efficiency comes mainly from excellent design, not excellent coding.
The Extreme programming movement advocates a simplistic approach to design and fast entry into the coding phase.
Extreme programming emphasizes the inefficiency and fact that the design rollup is revised by continuous refactoring (refactoring) after encoding: The high-level language code, in conjunction with the appropriate compiler optimizations, is approximately 90% efficient in assembly language. For some complex modern architectures, the efficiency is higher.
Fact 54: There is a tradeoff between time and space, and usually the improvement on the one hand decreases on the other.
Fact 55: Many software researchers are not investigating, but advocating.
Fallacy 1: To estimate costs and schedules, you should first estimate the number of lines of code.
Fallacy 2: Random test input is a good way to optimize your test.
Myth 3: Join with enough attention, all the errors are obvious.
Fallacy 4: Estimating future maintenance costs and making product update decision requirements requires reference to past cost data.
Myth 5: A good way to teach others to program is to teach others to write programs. (should be read first).

The facts and fallacies of software engineering (turn)