Richard Feynman, Challenger, Software Engineering

Transferred from:Http://coolshell.cn /? P = 1654(Cool Shell)

 

 

Source article: Link (this article mainly criticized the inappropriate "top-down" Design Method Based on the challenger issue and Richard Feynman's rigorous criticism report on NASA, I also summarized some points of view on the connection between software engineering and other projects. Translation skills are limited. please correct me)

In Florida, US east time January 28, 1986 11:39 A.M., the Challenger Space Shuttle executes a 6-day STS-51-L task, after the launch, its right-side solid rocket booster (src-solid rocket booster) the O-ring sealing ring (used to connect two-step booster) is invalid. The leaked hot steam reaches 5000 degrees Fahrenheit, directly evaporated the O-ring, and burned the adjacent external fuel tank. Within a few seconds, structural connection failure occurs in the external fuel tank, and the aerodynamic power quickly breaks down the space shuttle. 72 seconds after the shuttle flight rose, the booster fell off, causing the shuttle flight to slide out of the side. Almost as the pilot Michael J. Smith sent "Uh oh", the whole space shuttle was completely dismounted. For a moment, the space shuttle exploded and all seven astronauts were killed. At that time, I was just a child. I learned the tragedy from the scrolling news entries below the TV.

At that time, rocket booster engineers warned that the O-ring may have problems, but unfortunately, the NASA Management ignored the problem. American President Reagan appointed the Rogers committee to investigate the accident, including the famous physicist Richard Feynman. Its unruly attitude and direct approach are in stark contrast with the style of the Rogers committee. Chairman Rogers, a politician, commented that Feynman is a "real pain ". Finally, in the report submitted by the Committee, Feynman's reverse opinion was almost cleared. In addition, Feynman was threatened by the Chairman to remove his name from the report, but eventually they agreed to add an appendix to the report, but it's just my opinion-Appendix F-personal observations on reliability of shuttle.

 

This is a good report, because it is a talented report. It has a deep insight into some natural engineering things when implementing some highly reliable systems. Yes, I didn't put the words "Software Engineering" here, just engineering. However, Feynman's conclusion is very inseparable from our software development. This is the most basic thing, either software engineering or other engineering. Next, let's take a look at how Feynman says:

The construction method of the aerospace main engine isTop-down(Top down. The whole engine was designed to put everything together, and those details were not very mature at the time of design. So,When small parts (bearing, turbine blade, heat pipe, etc.) have problems,It takes us an expensive cost to find out the cause of the accident, and it is difficult to make changes.. To avoid problems, it is necessary to frequently maintain and replace important parts. Repair often does not solve the real cause.

It can be seen that in software development, the longer the bug exists throughout the process, the harder it is to solve this problem. Obviously, the top-down method is not familiar with the actual problems during the design, so the bug emerged from the design. However, we need to understand the differences between requirements and design. A clear and well-defined product is required, and design is a way to meet the requirements. Here, Feynman does not oppose the Feature Specification. He only opposes the top-down design method. For example, UML is the follower of the blueprint. Let's take a look at his remarks:

The main engine of the space shuttle is a very unusual machine. It is different from all previous engines. This is completely beyond the engineering experience of the previous engine system. Therefore, it is not surprising that many different processes and difficulties will appear in the project.However, unfortunately, this is achieved through top-down design, so those processes and problems are hard to be found to be corrected.. The engine life required by the design can complete 55 ignition tasks (equivalent to 27,000 seconds, that is, the first ignition takes 500 seconds), but in fact this is not completed. While the engine is currentlyFrequent maintenance and frequent replacement of important componentsSuch as turbine pumps, bearings, metal slices, and so on.

"The inappropriate top-down design method makes it difficult to identify and correct problems. In the end, the design requirements are not completed and the maintenance is frequent." Do these descriptive methods seem familiar to me? Is the software project we are working on every day different from this one? Feynman details why the "top-down" design makes it so difficult and painful to discover and solve these problems:

Many of the issues that have been solved are difficult to design at the beginning. Naturally, no one can determine that all the detected problems will occur, and some of them,We did not solve these problems in the right place based on the correct reasons.

Whether this is the Linux kernel or the aerospace engine, the basic issues during the design are the same. The "top-down" is one of the absurd ones, because the top-down mode pays too much attention to requirements and ignores the reality, however, the detailed knowledge below is absolutely necessary, and not all things can be abstracted. When talking about the Aviation Electronics System (another department of NASA ):

The software was carefully checked using the bottom-up method.First, each line of code has been checked. Then, the code segment, module, and some detailed functions have been verified.. The inspection scope is expanded step by step until new changes are combined to form a complete system. The complete output of this process became the final product and a new release. This department is completely neutral,Use software as a competitorKeep testing and verifying, just as you are a user of the software.

Yes, this is the unit test (unit test), which Feynman told everyone in 1986. Today, unit test is the most important part of software development activities (maybe you think it is coding ). It's not just unit test. "step-by-step incremental" and "hostile attitude" are all worth learning. We often hear people complain about software, because software engineering is too young and we still have a lot of knowledge, so there are always so many problems. This is completely nonsense! We are suffering from the fact that we always ignore the methods that have been fixed for a long time and are well-known and prove everything through experience and practice. Of course, in this regard, our management should also be responsible, especially for disordered time schedules, wrong incentive mechanisms, low-grade recruitment, and some systems that impair morale. The tension between "management" and "engineering" eventually becomes bad management. Feynman also talked about this in his report:

All in all, Computer Software Check systems andThe most responsible attitude. Yes, there is no self-deception, regardless of the solid fuel booster standard. However, it is certain that the relevant management departmentWe recommend that you cancel such complex and expensive unnecessary tests with the latest recommendations..

This is just a small segment. I picked it out because I pointed out my point of view, such as "the most responsible attitude" and "gradually deceiving myself ". I suggest you read the full text of the report to get a lot of truth. The following are some main points of view about software engineering:

• A project can be well managed only when it has a good relationship with its management.
• It is silly to design a large scale from the front end.
• Software Engineering is the same as other traditional engineering.
• Reliable systems are jointly guaranteed by nearly brutal tests, incremental bottom-up projects, and a highly responsible attitude.

There are still many good ideas in this report. If you feel it, please let me know.

(Full text)