Source code is the design

The source code is the design-general Linux technology-Linux programming and kernel information. The following is a detailed description. So far, I can still remember where I was when I had an epiphany and finally produced the following article. That was the summer of 1986. I served as a temporary consultant at the China Lake Naval Weapons Center in California. During this period, I had the honor to attend a seminar on Ada. During the discussion, an audience raised a representative question: "Are software developers engineers ?" I don't remember the answer at the time, but I still remember that I didn't really answer this question at the time. So I quit the discussion and began to think about how I would answer this question. Now, I cannot be sure why I remembered a paper I had read in Datamation magazine almost 10 years ago, but what prompted me to remember was something that was discussed later. This paper explains why engineers must be good writers (I remember this paper is about this problem-I haven't read it for a long time), but I have been dropping the tomb from the grave? What is the title of the bad guy holding the crane? Tan? Do you want to fight? Loose; loose? Why ?? How can I handle the problem? Crown sheath drops? Why? What are the heartbeats and other heartbeats? Hey, hey, what's the penalty? Me? Si Chen? Blank? 2 ?? Nai? Which of the following statements can be used? Is the title of the zombier? Qin Chen? What are the Mu s of tomb Tao? Why? Why is there a curtain? Cutting Die? Surname? Nakhon Jong-dong? (3) What are the benefits ?? Create? Success !? Br> regard the source code as an engineering document-design-completely subverts my views on my chosen career. It changes the way I view everything. In addition, the more I think about it, the more I think it clarifies the many problems that software projects often encounter. More specifically, I think most people do not understand this different view, or intentionally reject the fact that it is enough to explain many problems. A few years later, I finally had the opportunity to publish my opinion publicly. A paper on Software Design in C ++ Journal prompted me to write a letter to the editor about this topic. After several correspondence exchanges, the editor Livleen Singh agreed to publish my thoughts on this topic as a paper. The following is the article.
-- Jack Reecves, December, 22,2001

What is software design?
©Jack W. Reeves, 1992

Object-oriented technology, especially C ++, seems to have brought a great shock to the software industry. A large number of papers and books have emerged to describe how to apply this new technology. In general, questions about whether object-oriented technology is just a scam have been replaced by questions about how to make the smallest effort to get the benefits. The emergence of object-oriented technology has been around for some time, but this explosive popularity seems a bit unusual. Why do people suddenly pay attention to it? People have given a variety of explanations for this problem. In fact, there is probably no single reason. Maybe we can make a breakthrough only by combining multiple factors, and this work is in progress. Even so, in the latest phase of the software revolution, C ++ itself seems to be a major factor. Similarly, there may be many reasons for this question, but I want to give a slightly different answer: C ++ becomes popular, it makes software design easier and programming easier.
Although this explanation seems a bit strange, it is the result of careful consideration. In this paper, I want to focus on the relationship between programming and programming. Over the past 10 years, I have never felt that the entire software industry is unaware of a subtle difference between software design and what is true software design. As long as we see this, I think we can learn more about how to become a better software engineer from the popularity of C ++ growth. This knowledge is that programming is not building software, but designing software.
A few years ago, I saw a seminar discussing whether software development is an engineering discipline. Although I do not remember the results of the discussion, I remember how it prompted me to realize that the software industry has made some errors and compared the hardware engineering, while ignoring some absolutely correct comparisons. In fact, I don't think we are software engineers, because we don't realize what is true software design. Now, I am more confident about this.
The ultimate goal of any engineering activity is some type of documentation. When the design work is completed, the design documents are transferred to the manufacturing team. The team is a completely different group from the design team, and its skills are also completely different from the design team. If the design document correctly depicts a complete design, the manufacturing team can start building the product. In fact, they can start to build many objects of the product without any further designer intervention. After reviewing the software development lifecycle in my understanding, I came to the conclusion that the only software document that actually meets engineering design standards is the source code list.
People have made a lot of arguments about this point of view. Both those who agree and those who disagree are enough to write countless papers. This article assumes that the final source code is the real software design, and then carefully studies the results of this assumption. I may not be able to prove this point, but I want to prove that it does explain some of the observed facts in the software industry, including the popularity of C ++.
When we regard code as the result of software design, one result completely overwrites all other results. It is very important and obvious, and because of this, it is completely a blind spot for most software organizations. The result is that software construction is cheap. It is not expensive at all; it is very cheap and almost free. If the source code is software design, the actual software build is completed by the compiler and connector. We often refer to the process of compiling and connecting to a complete software system as "building once ". The main investment in software building devices is very small-only one computer, one editor, one compiler, and one connector are actually needed. Once you have a Build Environment, it takes a little time to build the actual software. It may take a long time to compile a C ++ program with 50 000 lines, but how long does it take to build a hardware system with the same design complexity as 50 000 lines of C ++ programs?
Taking the source code as another result of software design, software design is relatively easy to create, at least mechanically. Generally, writing (that is, designing) a representative software module (50 to 100 lines of code) takes only a few days (fully debugging it is another topic, it will be discussed later ). I would like to ask if there are any other disciplines that can generate designs with the same complexity as the software in such a short period of time. However, first, we must figure out how to measure and compare complexity. However, it is obvious that software design can become very large quickly.
Assuming that software design is relatively easy to create, and there is no cost to build it in essence, it is not surprising that software design is often incredibly large and complex. This seems obvious, but the importance of the problem is often ignored. Projects in schools usually have thousands of lines of code. Software products with 10 million lines of code (Design) are also discarded by their designers. We have long been concerned about simple software. The Design of typical commercial software is composed of hundreds of thousands of lines of code. Many software designs have millions of lines of code. In addition, software design is almost always evolving. Although the current design may only have thousands of lines of code, in the product life cycle, it may actually need to write many times of code.
Although there are some hardware designs that seem as complicated as software design, pay attention to two facts about modern hardware. First, the results of complex hardware engineering may not always be correct. At this point, it does not have the criteria that trust us like software. Most of the microprocessors were sold with logic errors: bridge collapse, dam breakdown, plane crashes, and thousands of cars and other consumer goods recalled-all of which are new to us, all of these are results of incorrect design. Second, the complex hardware design corresponds to the complex and expensive build phase. As a result, the capabilities required to make such a system limit the number of companies that can actually produce complex hardware design. There is no such restriction for software. Currently, hundreds of software organizations and thousands of extremely complex software systems exist, and the number and complexity of software systems are growing every day. This means that the software industry cannot find a solution to its own problems by imitating hardware developers. If something is the same, it means that when CAD and CAM can help hardware designers create more and more complex designs, hardware engineering will become more and more like software development.
Designing Software is an activity that manages complexity. Complexity exists in the software design itself, in the company's software organization, and in the entire software industry. Software design is very similar to system design. It can span multiple technologies and often involves multiple branch disciplines. The specification of the software is often not fixed and rapidly changing. This change often occurs when the software is being designed. Similarly, software development teams are often not fixed and often change in the middle of the design process. In many ways, software is more complex than hardware in society or organic systems. All of these make software design a difficult and error-prone process. Although none of these are creative ideas, today, nearly 30 years after the start of the software engineering revolution, compared with other engineering industries, software development still looks like an untrained (undisciplined) skills.
The general opinion is that when a real engineer completes a design, no matter how complicated the design is, they are very confident that the design can work. They are also very confident that the design can be built using recognized technologies. To do this, hardware engineers spend a lot of time verifying and improving their designs. For example, consider a bridge design. Before such a design is actually built, engineers perform Structural Analysis-they build computer models and perform simulation, and they build proportional models and perform tests in wind tunnels or using other methods. In short, designers will use all the methods they can think of to prove that the design is correct before building. The design of a new aircraft is even more serious; a prototype of the same size as the original must be built, and flight tests must be carried out to verify the expectations in the design.
For most people, there is obviously no project as strict as the hardware design. However, if we regard the source code as a design, we will find that software engineers have actually done a lot of verification and Improvement on their design. The software engineer calls it test and debugging instead of engineering. Most people do not regard testing and debugging as true "engineering"-it is certainly not seen in the software industry. The reason for this is that the software industry rejects code as a design, rather than any actual engineering difference. In fact, the test model, prototype, and circuit test board have become recognized components of other engineering disciplines. Software designers do not have or do not use more formal methods to validate their designs because of the simple economic pattern of the software build cycle.
The first revelation: Building a design and testing it is cheaper and easier than doing anything else. We don't care how many builds are done-these builds have almost zero cost of time, and if we discard the build, the resources it uses can be completely reused. Please note that testing is not only about making the current design correct, but also part of the process of improving the design. Hardware engineers of complex systems often build models (or, at least, they use computer graphics to visually present the design ). This gives them a "feeling" of design, which is not possible simply by checking the design. For software, building such a model is neither impossible nor necessary. We only build the product itself. Even if formal software verification can be performed automatically like a compiler, we will still perform build/test loops. Therefore, formal verification has never had much practical significance for the software industry.
This is the reality of today's software development process. A growing number of people and organizations are creating more complex software designs. These designs are first written in some programming languages and then verified and improved through Build/test cycles. The process is prone to errors and is not very strict. A considerable number of software developers do not want to believe that this is the way the process operates. This makes the problem more complex.
At present, most software processes try to separate different stages of software design into different categories. Encoding starts only after the design at the top layer is completed and frozen. Testing and debugging are only necessary to clear build errors. Programmers are in the middle. They are construction workers in the software industry. Many people think that if we can stop programmers from "hacking" and build them according to the design they have given (and even make fewer mistakes in the process ), then software development can become mature and become a real engineering discipline. However, this is impossible as long as the process ignores engineering and economics facts.
For example, any modern industry cannot tolerate a return rate of more than 100% during its manufacturing process. If a builder often fails to build correctly for the first time, he will soon be unemployed. However, in the software industry, even the smallest piece of code may be corrected or completely rewritten during testing and debugging. In a creative process (such as design), we acknowledge that such improvement is not part of the manufacturing process. No one expects the engineer to create a perfect design for the first time. Even if she does, it must still undergo the improvement process to prove that it is perfect.
Even if we have not learned anything from the Japanese management method, we should also know that blaming the workers for making mistakes in the process is not conducive to productivity improvement. We should not constantly force software development to conform to incorrect process models. On the contrary, we need to improve the process so as to help rather than hinder the generation of better software. This is the core test of "Software Engineering. The project is about how you implement the process, not about whether a CAD system is required to generate the final design document.
An overwhelming question about software development is that everything is part of the design process. Coding is the design, testing and debugging are part of the design, and we usually think that the design is still part of the design. Although software is cheap to build, it is incredibly expensive to design. The software is very complex and has many different design contents and the design considerations caused by them. The problem is that all different aspects are interrelated (just like in hardware engineering ). We hope that the top-level designers can ignore the details of the module algorithm design. Similarly, we hope that programmers do not have to consider the top-level design issues when designing the internal algorithms of the module. Unfortunately, problems at the design level intrude into other layers. For the success of the entire software system, selecting algorithms for a specific module may be equally important as any high-level design issue. There is no importance level in different aspects of software design. An incorrect design in the lowest layer module may be as fatal as an error in the highest layer. Software design must be complete and correct in all aspects; otherwise, all software built on the basis of the design will be wrong.
Software is designed hierarchically to manage complexity. When a programmer considers a detailed design of a module, there may be hundreds of other modules and thousands of details, which cannot be taken into account at the same time. For example, some important aspects of software design are not completely in the scope of data structures and algorithms. Ideally, programmers should not consider these other aspects of design when designing code.