Richard Hamming: Chapter 28. Systems Engineering

The first rule of system engineering: "If you optimize the components, then, most likely, the system performance will be corrupted."

Hi, Habr. Remember the awesome article "You and your work" (+219, 2146 bookmarks, 339k reads)?

So Hamming (yes, yes, self-checking and self-correcting Hamming codes ) has a whole book based on his lectures. Let's translate it, because the man is talking.

This book is not just about IT, it is a book about the thinking style of incredibly cool people. “This is not just a charge of positive thinking; it describes the conditions that increase the chances of doing a great job. ”
')
We have already translated 4 chapters.

Chapter 28. System Engineering

(For the translation, thanks to Julia Perunovskaya, who responded to my call in the “previous chapter.”) Who wants to help with the translation - write in a personal or mail magisterludi2016@yandex.ru

Allegory is often more effective than a direct statement, so let me start with a parable. The man watched as they built the cathedral. He asked the bricklayer why he was grinding the stones, and the bricklayer replied, "I make stones." He asked the stone carver what he was doing, "I cut the gargoyle." And so he asked everyone, and they all told in detail what they were doing. In the end he approached the old woman who was sweeping the territory. She said "I am helping to build a cathedral."

If in a regular campus you decided to interview a certain sample of professors about what they were going to do in the next academic hour, you would hear that they would “teach the simplest fractions”, “show how to find the moment of normal distribution”, “explain the module elasticity and its measurement ", etc. I doubt that you would often hear from the professor the phrase "I am going to train students and prepare them for their future career."

In both cases, you will say that education and training is a larger goal that is so obvious that it does not need to be mentioned. But I doubt that you yourself really believe in it. In most cases, each person is immersed in the details of one specific part of the whole and does not think about how what he does affects the overall picture. Such a vision is typical for most people. They demonstrate narrow views in their work and rarely, if ever, associate it with the more general goals of the system. However, with external pressure, they are ready to admit that these general goals are the real goals of the system. Such narrowness of views is the main characteristic of the bureaucrat.

To reach the summit, you need to have a wider vision — at least when you are already there. Systems engineering is an attempt to always keep the main goals in mind and understand what each local action is done for and how it affects the overall result. However, there is not one particular big picture here. For example, when I first had my own computer, I assumed that the main goal was to use it daily for as many arithmetic operations as possible. It took a little more time before I realized that the main idea was the importance of calculations, and not the amount of calculated information. Later, I realized that the most important calculations were made not for the Mathematical Department, where I was, but for the research unit. Naturally, I soon realized that the greatest value from the new machines can only be learned by scientists themselves when working directly. Then they would be able to understand the full value of computers that can be used in their work, reducing the actual number of calculations, but at the same time increasing their value for Bell Telephone Laboratories (Bell Telephone Laboratories). However, later I realized that I should pay attention not only to the needs of the Research Department, but also to all the needs of Laboratories. Then it was AT & T, the Country outside AT & T, the scientific and engineering communities, and, ultimately, the whole world. Thus, I had obligations to myself, my department, division, company, parent company, country, world of scientists and engineers, and every inhabitant of the planet. There were no clearly defined boundaries, at any moment I could draw them myself and ignore everything that did not fall inside.

The commitments in each case were: (1) a direct contribution, (2) a long-term contribution, and (3) a very long-term contribution. I also understood that under clauses (2) and (3) one of my functions in the research department was not so much a solution to existing problems as developing methods for solving problems, expanding the range of possibilities and teaching others what I was able to find so that they could continue to apply, continue and improve the results of my efforts.

In system engineering, it is very easy to say the right words, and many people have learned to speak them when asked questions on this topic, but as in many sports such as tennis, golf or swimming, doing everything you need is generally difficult. Therefore, system engineers should be judged not by what they say, but because they end up doing and producing. There are many people who talk about a good game, but in fact can not play it.

The first rule of system engineering

If you optimize the components, then most likely, the system performance will be corrupted.

This is a very difficult moment to understand. It usually seems very reasonable that the whole system will improve if its individual components are improved, but this is not true. More likely, system performance will degrade. As a simple example, I worked with a differential analyzer and so succeeded in solving important problems that it became necessary to purchase two more analyzers. We ordered the second one in order to connect it to the current one, so that they could perform calculations either separately from each other or jointly. They built a second model and wanted to improve it, to which I agreed, but with the condition that this does not interfere with the work of the entire machine. Came the day of inspection before dismantling and transporting the car to our place. I started testing it, my friend reluctantly helped me, who claimed that I was just wasting my time. The car failed the first test! The test was a classic solution to a differential equation.



The solution of which, of course, is y = cost. Then you draw the graphs y (t) and y´ (t), and you should have a circle. The measure of accuracy is how well it closes itself, cycle by cycle.

Therefore, we tried to test with other components, but got the same result. My friend had to admit that something was completely wrong, so we called the people who installed and set up the equipment to indicate an absolutely obvious problem. We watched how they spent a lot of time with the equipment until we got tired and my friend and I set off for lunch. When we returned, they had already figured out what the problem was. They did improve the amplifiers, but now the flow, with insufficient grounding, caused a circuit to leak out! They just had to install a much heavier ground with a copper coating, and everything became good. As I mentioned earlier, the improvement of one of the components in a similar machine, even taking into account the fact that each component is completely independent, led to a disruption in system performance! This is a trivial example, but it shows the meaning of this rule. Usually, the effect of improving a component is not as strong and obvious, but it is equally harmful for performance.

You most likely still don’t believe this rule, so let me apply it to you. Most of you, when preparing for the exam, reread and memorize the material at the very last moment at the end of the semester, which for the most part is absolutely not productive in relation to the education you want to receive. You perceive your problem as the need to successfully pass exams for each course separately, successfully closing each semester separately, while in fact you understand that what matters is what will come from your knowledge at the end of training, and not on each of its stages. For the last two years of my undergraduate studies at the University of Chicago, there were rules for passing one exam based on 9 courses of major specialization, and another based on 6 courses of additional specialization. And it was this result that was important, and not the grades that students received during the entire course of study. At that moment I understood for the first time what a systematic approach to education is. When you choose a specific course, it is not important what grade I will pass the exam or how I will please the professor with my knowledge, but what I will learn and understand the subject so that even after some time, for example, after two years, I can still apply knowledge gained in this course.

Dental before the exam - a waste of time. You really understand this, but the behavior of most of you indicates a categorical rejection of this truth. As I mentioned earlier, in the evaluation of the work of the system engineering words have little meaning, it is important what has been done. Professors as well as those who pay your tuition bills, and perhaps some of you believe that what you are taught will most likely be very useful in your future career. But you continue to optimize system components to the detriment of the whole! Systems engineering is a process that is difficult to follow, so it’s easy to get lost in the details! Easy to say, but hard to do. This example is intended to show you the reality of my reasoning: many people know what to say, but not many can actually put it into practice when the time comes to act in the real world. Most of you can not!

As another example of the impact of optimizing system components, consider the math course in college. Over the years, we have optimized courses in Mathematical Analysis and Linear Algebra, and removed everything that is not directly related to each of these courses. As a result, if you look at the whole, there are big gaps in learning Mathematics. We practically do not touch (1) an important method of mathematical induction, (2) after a brief mention in connection with quadratic equations in algebra, we almost completely ignore any mention of complex numbers until that fateful day when complex eigenvalues ​​and eigenfunctions appear, and a poor student gets acquainted with two new complex concepts at the same time and, naturally, this confuses him, (3) briefly mentions the useful method of undetermined coefficients, (4) are almost completely ignored, the proof lstva impossibility, (5) is ignored discrete mathematics, (6) no efforts are being made to bring the reflections of students from training examples to important concepts applicable in the real world. So it goes on and on, most parts of good mathematics education are omitted as a result of the desire to optimize individual courses. Usually, the internal structure of the Mathematical analysis and the central role of limits are presented as insignificant.

All the proposed transformations of the standard course of Mathematical Analysis, which I studied (and there are many), never begin with the question: "What is a general Mathematical Education, and what, therefore, should be on the course of Mathematical Analysis?". Almost no one tries to incorporate the use of computers into education, since they do not study, which generally includes mathematical education, of which the course should become a part.

A systematic approach to learning does not flourish, only enthusiasts of different points of view are trying to blind things themselves that would be well suited to local initiatives. In most situations, the question “What is a common problem that includes this part?” Is considered as too extensive and, therefore, the sub-optimization of the courses continues. Few among the people planning reforms in any system first try to understand the main problem of the whole system, they immediately attack the very first symptom that they managed to detect. In the end, the thing for which the eye first gets hooked, no matter what it is, is not what the system needs.

Recently, I tried to think about the history of system engineering. And the fact that the system was designed does not mean that the designer kept in mind the system itself, and not its individual components. The earliest system I read about in detail is the Venetian arsenal at its dawn around 1200-1400. They had a production line, and by the time the ship left the line, the ropes, the masts, the sails, and even the trained crew were in place and the ship immediately sailed! At regular intervals, the new ship was leaving the arsenal. This is an early example of “on time” production, including people who were properly prepared at the time the equipment was manufactured.

The first railways were, of course, systems. But it is not clear to me whether the first builders really did not try to optimize each individual part and didn’t really think until everything worked, that it was a system and it was necessary to think about how its parts should interact in order to achieve a decently functioning system.

I suspect that it was the telephone company that was the first to encounter the problem of system engineering. To provide the appropriate service, all parts must be interconnected and provide high reliability. Since the beginning of work, the company has provided not only equipment, but also service. This is a big difference. If you simply create something, and then leave it to other people for use - this is one thing, but if you are going to maintain it as a service, then this is completely different! Many clearly encountered small systems before that, but the telephone system was larger and more complex than anything before it. They also discovered, perhaps for the first time, that there is no economies of scale in expansion. This, on the contrary, entails losses. Each new client had to be connected with other existing ones, therefore the costs for each new client were higher than for the previous one. Accordingly, the system should be well thought out.

I am not going to pretend that I understand how I, having a classical mathematical education, became a systems engineer, but I became one. I assume that the grain originated during my college years, but really sprouted only in Los Alamos, where it became obvious to everyone that each component must be properly designed and coordinated, including the process of placing the bomb in a special compartment in the current aircraft. At the same time, it was necessary to do the work quickly, before the enemy, who also designed the bomb, did it.

Nike's guided missile systems, the computer systems I worked on, and many other aspects of working at Bell Labs taught me system engineering — not abstractly, but daily examples of idiots who didn't understand the whole as a whole and saw only its components. . I already noticed that I did not immediately understand how the systems approach works, since I worked with computers, but nevertheless, I gradually realized that computers were built as part of an organization engaged in the development of research, of course, very important. But it was the value of computers in this system that was important in the long run: how well the machines helped to achieve the goals of the organization and society, and not just facilitate the work of the staff who used them.

Here we need to recall another point that is now clearly seen in the creation of software and equipment and reveals a new problem of system design. Everything is changing so quickly that the system will be constantly updated, and it is difficult to understand initially what changes may occur in the future at all. Flexibility should be part of the modern design of things and processes. Flexibility in design provides not only an opportunity to better cope with the changes that will inevitably arise after the installation of the system, but also contributes to your own work in the form of small changes that inevitably occur both in the later design stages and during field tests of the system. I did not understand how much change there could be during the tests, before I took part in the field test of the Nike project on Kwajalein Islands. We installed the equipment, and in parallel with the process there was a constant stream of changes being made to the installation!

Second rule

Part of the design of system engineering - preparing for changes to get through them successfully and not to reduce the performance of other parts.

Coming back to your education: our real task is not to prepare you for our past or even the present, but to prepare you for your future. That is why I emphasized the importance of what is currently considered to be the basics of various areas, and deliberately neglected the current details that probably exist in the short term. As I wrote earlier, the half-life of design approaches is 15 years - half of the ideas that you learn now will be useless after 15 years.

Third rule

The more precisely you meet the specifications, the worse the performance will be at overload.

The truth of this rule is evident when building a bridge with a certain load. The closer the compliance to the prescribed load, the faster the bridge will collapse when the limit is exceeded. The same can be seen in the central office of the telephone company. If you design a system under maximum load, then even with a small excess of traffic, the work of the entire system immediately deteriorates. Consequently, a good design of the project gradually reduces performance when the specifications set are exceeded.
While preparing to write this chapter, I once again re-read a set of unpublished essays: “One Man's Systems Engineering” G.R. Westerman (1975), then still working at Bell Telephone Laboratories. — «, » . , . , , :

1. One Man's Systems Engineering. /
2. What is Systems Engineering? / ?
3. On the Objective. /
4. What Does a Systems Engineer Do? / ?
5. The Framework of Systems Engineering. /
6. Organization and Systems Engineering. /
7. Objectives and Policy Makers. / ,
8. On the Methodology of Systems Engineering. /
9. Evaluation and (Un)Common Sense. / /
10. Envoy. /

, .

, , . , , - . , .

He believes that the specialists gathered in the team are the basis of system engineering, and between projects they must return to their specialties in order to maintain an appropriate level of their experience. Using the team to fight fires too often is harmful, as they will lose experience in their areas.

, . , , . , , , , . . , 3- ( ) ( — ) , 5- , . . 10- , , . / . . . — ό .

The second reason why design never stops is that the solution proposed for the original task usually leads to a deep understanding and dissatisfaction on the part of the engineers themselves. Moreover, while the design phase is constantly moving from the proposed solution to the evaluation and vice versa, again and again, there comes a time when this process of rethinking must stop, and the real task is to get a solution. Thus, engineers understand that in the long run, their solution is still suboptimal.

Westerman, like me, believes that while the client may be aware of some of the symptoms, he may not understand the real reasons for them. And this is silly, trying to cure only the symptoms. Thus, while system engineers should listen to a client, they should also try to extract a deeper understanding of the phenomenon from him. Therefore, the system engineer’s job is to define in a deeper sense what the problem is and how to move from symptoms to real causes.

, , , , . , . , , .

, — , , , , . , , , , , .

, . , . : . — , . , , , — . , , — , .

Westerman believes that, apparently, the art of systems engineering is best studied in a team that includes both old and new faces. At the same time, he says that more experienced colleagues should be gradually removed from the process and introduce new people to the team. I do not know how to convey my personal experience of the "lone wolf". I can only talk about what I did and how I behaved in certain situations. Usually the actual circumstances are so complex that it takes a lot of time to overcome foreign policy factors, organizational habits, personal qualities of the team that will run the final system, working conditions in the field, traditions, etc. All these factors have a strong influence on solving the problem system. Usually,the decision becomes a greater compromise between conflicting goals and a rare understanding of the importance of intangible parts of the border, which forms the structure of the answer, on the part of the student. Thus, the real problems of systems engineering is almost impossible to manifest clearly and in detail. Instead, use learning situations and stories that, while simplifying some details, do not distort the overall picture too much. If you once again return to the previous chapters, you will find many examples - in many ways, simplified stories about systems engineering situations. I believe that I am a committed system engineer and will inevitably always lean in this direction. But let me clarify again. Systems engineering should be built on a solid basis of classical simplification to specific problems with a specific solution. I doubt,that this can be taught ab initio.

, . , , , . , , , . , : , — , , , , . , . , , - !

, Nike. , . , Nike . , , , . , , , , . , , , . , Nike , , «» . , ! , . , , , . , .

— , . á , , , .

To be continued...

Who wants to help with the translation - write in a personal or mail magisterludi2016@yandex.ru