Richard Hamming: Chapter 28. Systems Engineering

The first rule of systems engineering: “If you optimize the components, then most likely the system performance will be spoiled.”

Hi, Habr. Remember the awesome article “You and Your Work” (+219, 2146 bookmarked, 339k reads)?

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

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 conditions that increase the chances of doing a great job. ”

We have already translated 4 chapters.

Chapter 28. Systems Engineering

(Thank you for translating Yulia Perunovskaya who responded to my call in the “previous chapter.”) Who wants to help with the translation - write in a personal email or mail to magisterludi2016@yandex.ru

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

If on a regular campus you decide to interview some sample of professors about what they are going to do in the next academic hour, you would hear that they would: “teach simple 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 educate students and prepare them for their future careers."

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 that. 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 characteristic of most people. They demonstrate narrow views in their work and rarely, if ever, associate it with the more general goals of the system. Nevertheless, under external pressure, they are ready to admit that it is precisely these common goals that are the real goals of the system. Such narrow views is the main characteristic of a bureaucrat.

To climb to the top, 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 why each local action is performed and how it affects the overall result. However, there is no one particular large picture. For example, when I first got 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 is 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, which I was in, but for the research unit. Naturally, I soon realized that the greatest value from new machines can be extracted only by scientists themselves when working directly. Then they could 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. 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 the Laboratories. Then it was AT&T, a 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, the world of scientists and engineers, and every inhabitant of the planet. There were no clearly defined boundaries,

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

It is very easy to say the right words in systems engineering, and many people have learned to speak them when they are asked questions under this topic, but like in many sports such as tennis, golf or swimming, it is difficult to do everything you need as a whole. Therefore, system engineers should be judged not by what they say, but because they ultimately do and produce. There are many people who talk about a good game, but in fact they can’t play it.

The first rule of systems engineering

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

This is a very difficult moment to understand. It usually seems very reasonable that the whole system will improve if its individual component is improved, but this is not true. It is more likely that system performance will deteriorate. 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 can make calculations either separately from each other, or jointly. They built a second model and wanted to improve it, which I agreed to, but on the condition that this does not interfere with the operation of the entire machine. The day of inspection came before dismantling and transporting the car to our place. I started testing it, my friend reluctantly helped me, who claimed that I was wasting my time. The machine failed the first test!



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

Therefore, we tried to test with other components, but got the same result. My friend had to admit that something was going completely wrong, so we called people who installed and set up the equipment to indicate an absolutely obvious malfunction. We watched how they fiddled with the equipment for a long time, until we were tired and my friend and I went for lunch. When we returned, they already figured out what the problem was. They really improved the amplifiers, but now the flow with insufficient grounding caused a leak from the circuit! They just had to install a significantly heavier copper-coated ground, and everything was fine. As I mentioned earlier, improving one of the components in a similar machine, even though each component is completely independent, led to a violation of system performance! This is a trivial example, but it shows the meaning of this rule. Usually, the effect of improving a component is not so strong and obvious, but equally detrimental to performance.

You most likely still do not believe in this rule, so let me apply it to you. Most of you, when preparing for the exam, re-read 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 very education that you want to get. 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 is built up from your knowledge at the end of training, and not on each of its stages. During my last two years of undergraduate studies at the University of Chicago, there were rules that required you to take one exam based on 9 core specialization courses, and another, based on 6 additional specialization courses. And it was this result that was important, and not the grades that students received throughout the training. At that moment, I first understood what a systematic approach to education is. When choosing a specific course, it’s important not what grade I pass the exam or how to please the professor with my knowledge, but what I will learn and understand the subject so that even after a while, for example, after two years, I can still apply knowledge gained in this course.

Cramming before an exam is 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 system engineering, words have little meaning, what is done is important. The professors, as well as those who pay the bills for your studies, 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 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 cannot!

As another example of the impact of optimizing system components, consider teaching college math courses. 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, when viewed as a whole, large gaps appeared in the teaching of Mathematics. We practically do not touch on (1) the 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 the poor student gets acquainted with two new complex concepts at the same time and, of course, this confuses him, (3) the useful method of indeterminate coefficients is briefly mentioned, (4) evidence of impossibility is almost completely ignored, (5) discrete mathematics are ignored, (6) efforts are not made to bring students' thoughts from teaching examples to meaningful concepts applicable in the real world . This can be continued further, most of the good mathematical education is omitted as a result of the desire to optimize individual courses. Usually, the internal structure of the Mathematical Analysis and the central role of the limits seems to be insignificant. This can be continued further, most of the good mathematical education is omitted as a result of the desire to optimize individual courses. Usually, the internal structure of the Mathematical Analysis and the central role of the limits seems to be insignificant. This can be continued further, most of the good mathematical education is omitted as a result of the desire to optimize individual courses. Usually, the internal structure of the Mathematical Analysis and the central role of the limits seems to be insignificant.

All the proposed transformations of the standard course of Mathematical Analysis that I have studied (and there are many of them) never begin with the question: "What is the general Mathematical education, and what, therefore, should be on the course of Mathematical analysis?". Almost no one is trying to include the use of computers in education, since they are not studying what mathematics education generally includes, of which the course should become a part.

A systematic approach to training does not flourish, only enthusiasts of different points of view try to create things themselves that would be well suited to local initiatives. In most situations, the question “What is the general problem that this part is part of?” Is seen as too extensive and, therefore, suboptimization of courses continues. Few 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 was discovered. As a result, what the eye catches first, it doesn’t matter what it is, it’s not what the system needs.

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

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

I suspect that it was the telephone company that first encountered the problem of systems engineering. To provide the appropriate service, all parts must be interconnected and provide high reliability. From the beginning, the company has provided not only equipment, but also service. This is a big difference. If you just create something, and then leave it for other people to use - this is one thing, but if you intend to support this as a service, then this is completely different! Many obviously came across small systems before that, but the telephone system was larger and more complex than anything before its inception. They also discovered, perhaps for the first time, that there is no economies of scale in the extension. This, on the contrary, entails losses. Each new client needed to be connected with other existing ones, therefore, costs were higher for each new client 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 suppose that the grain originated during my college years, but really only sprouted in Los Alamos, where it became obvious to everyone that each component should be properly designed and coordinated, including the process of accurately installing the bomb in a special compartment in the current aircraft. At the same time, work had to be done quickly, before the enemy, who also developed the bomb, did it.

Nike’s guided missile systems, the computer systems I worked on, and many other aspects of working at Bell Telephone Labs taught me systems engineering — not abstractly, but with daily examples of those idiots who didn't understand the whole as a whole and only saw its components . I already noticed that I did not immediately understand how the system 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, which is certainly very important. But it was precisely the value of computers in this system that was important in the long run: how well the machines helped achieve the goals of the organization and society, and not just facilitate the work of the personnel who used them.

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

Second rule

Part of the design of systems engineering is preparing for changes in order to get through them successfully and not reduce the performance of other parts.

Returning 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 the foundation of various areas, and deliberately neglected the current details that are likely to exist in the short term. As I wrote earlier, the half-life of design approaches is 15 years — half the ideas that you will learn now will be useless after 15 years.

Third rule

The more accurately you meet the specifications, the worse the performance will be when overloaded.

The truth of this rule is obvious when building a bridge with a certain load. The closer the fit is 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 the system for maximum load, then even with a small excess of traffic, the operation of the entire system immediately deteriorates. Consequently, a good project design will gradually reduce productivity when exceeding established specifications.
In preparation for writing this chapter, I re-read a set of unpublished essays: “One Man's Systems Engineering” G.R. Westerman (1975), then still working at Bell's Telephone Labs. These essays are the only deeply philosophical discussion on the topic of “what, how and why” in systems engineering. I will depart a little at certain points from the words of the author, but in general I agree with his theses. I can only summarize what he discusses in his essays under the names:

1. One Man's Systems Engineering. / Single-person
Systems Engineering 2. What is Systems Engineering? / What is Systems Engineering?
3. On the Objective. / About Goal
4. What Does a Systems Engineer Do? / What does a system engineer do?
5. The Framework of Systems Engineering. / Structure of Systems Engineering
6. Organization and Systems Engineering. / Organization and System Engineering
7. Objectives and Policy Makers. / Goals and Policy
Makers 8. On the Methodology of Systems Engineering. / About the methodology in System Engineering
9. Evaluation and (Un) Common Sense. / Assessment and common sense / unusual approaches
10. Envoy. / Messenger

This list clearly shows the breadth of his views that arose while working on military projects and solving systemic problems in the telephone company.

He believes more in a group of people who deal with system engineering problems than in the analysis of individual problems. While I, with my limited experience in computing, worked alone without the opportunity to discuss the correct use of computers with someone. Of course, his tasks were much more difficult than mine.

He believes that the experts who have gathered in the team are the foundation of systems engineering, and between projects they should 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 the experience honed in their fields.

We both agree that the system engineering process never ends. One of the reasons is that solving the problem changes the environment itself and creates new tasks that need to be solved. For example, when I first started managing the computer center, I believed that small tasks were relatively more important than large ones. I wanted to provide a constant and reliable service. Therefore, I set one hour in the morning and afternoon, during which it was allowed to run only 3 (or less) minute tasks (mainly software testing) and, if the task was performed for more than 5 minutes, I had to stop it. Even if the task was almost completed. As a result, people with 10-minute problems broke them into three small pieces, distributing them among other employees, and conducted them within the framework of the rules I set. Thus, they increased the load on data input / output systems. Having my solution changed the reaction of the system. The optimal strategy for one employee was clearly contrary to the optimal strategy for the entire laboratory. One of the functions of a system engineer is to stop most of the local optimization of individuals and achieve global optimization of the entire system.

The second reason design never stops is that the solution proposed to 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 assessment and vice versa, again and again, there comes a time when this process of rethinking should 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 symptoms, he may not understand their real causes. And it's stupid, trying to cure only the symptoms. Thus, while system engineers should listen to the client, they should also try to get a deeper understanding of the phenomenon from it. Therefore, the job of a system engineer is to determine in a deeper sense what the problem is and how to move from symptoms to real causes.

Since the system itself, the solution to which it is necessary to find, is not defined, and the boundaries of the problem are mobile and tend to expand with each new iteration of the search for solutions, often there is no final solution. However, each evaluation and decision cycle is worth the effort. A decision that does not prepare for the next round with a slightly more increased understanding is not a solution at all.

I think that the essence of systems engineering is the acceptance of the fact that this is not about a specific problem or final solution, but rather about evolution, as a natural state of affairs. This, of course, is not what they are taught in school, where they show you specific problems that have specific solutions.

How, then, can schools adapt to the current situation and teach systems engineering, which is becoming increasingly important in view of the development of our society. The idea of ​​a laboratory approach to systems engineering is attractive until you realize the consequences. The systems engineering described above largely depends on standard school teaching: specific methods are suitable for solving certain problems. A new element here is the formulation of a specific problem against the backdrop of the uncertainty that underlies our society. We cannot ignore the traditional approach to teaching, especially since schools have neither the time nor the resources to introduce a new subject - systems engineering. I suggest that the best we can do in this situation is to constantly mention

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 turn out to be so complicated that it takes a lot of time to overcome the factors of foreign policy, organizational habits, personal qualities of the team that will launch 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 great compromise between conflicting goals and a rare understanding of the importance of the intangible parts of the border, which forms the structure of the response, on the part of the student. Thus, the real problems of systems engineering are almost impossible to express clearly and in detail. Instead, it is worth using learning situations and stories that, while simplifying some of the details, do not distort the overall picture too much. If you go back to the previous chapters again, you will find many examples - in many ways simplified stories about systems engineering situations. I believe that I am a convinced systems engineer and will inevitably always lean in this direction. But let me clarify again. Systems engineering should be built on a solid foundation of classical simplification to specific problems with a specific solution. I doubt,

I have seen so many proposed solutions that correctly solved the wrong problem. In a sense, systems engineering is trying to solve the right problems, but perhaps in a slightly wrong way. However, in its implementation, the solution is temporary, and during the next iteration of the design, perfect errors will be identified, increasing the general understanding of the system. I already mentioned this, but let me say it again: a solution that does not provide a deeper understanding is a bad solution, but it is possible that this is all that can be done in the current time limit. The goal of systems engineering should be a deeper and longer-term understanding of the essence of the problem, while the client always wants to see an immediate solution to the current symptoms. Again, the conflict leading to meta-system engineering!

As an example of an in-depth understanding of the system and its problems, I want to consider the Nike guided missile project. At first, the goal was to build a rocket that would bring down a single target. After we fulfilled this goal, we began to think about the Nike missile battery and how to coordinate each of the missiles under attack from the enemy air fleet. Then came the day when we began to think about which goals and cities to protect and which not. We began to understand that all goals should be equally expensive for the enemy, there should be no goals that would be less or more protected than others. Each target had to be protected in direct proportion to what damage the enemy could inflict by attacking it. Thus, we began to see Nike missiles as just a device that would force the enemy to pay for the damage they caused, nor did we leave him “cheap” goals. How different this view is from the one with which we started development! This is a good illustration of the fact that each solution should bring a development of understanding of the problem. Those first symptoms that you point out will quickly disappear from sight as soon as you succeed in this. The goal will constantly change as you and your client deepen their understanding.

Systems engineering is certainly an exciting profession that is difficult to practice. There is a great need for real system engineers, just like the need to get rid of those who just tell a good story, not being able to effectively play the game itself.

To be continued ...

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