There is a good anecdote on this topic: Physicist, mathematician and engineer were given the task to find the volume of a red rubber ball. The physicist dipped the ball into a glass of water and measured the volume of the displaced liquid. The mathematician measured the diameter of the ball and calculated the triple integral. The engineer took out his “Table of Volumes of Red Rubber Balls” from the table and found the correct value.
There are other types of engineering heuristics that are not at all related to engineering calculations and design-design techniques: what is an engineer
● There are always one more stakeholders than you know; the stakeholders you know always have one more need than you know (this is the sixth major Tom Glib engineering heuristic).
● Order beats the class (in large projects, the orderly work of a team of mediocre specialists beats the chaotic work of high-class stars).
Nevertheless, science and engineering are closely related: heuristics in simpler systems are replaced by scientific theories, including in the form of computer models (the difference: a correctly applied theory gives a reliable answer, and heuristics may be lying), and a place for trial and error is shifting towards more complex systems that are poorly described by available scientific theories.
Formal (theoretical, following the laws of logic, and not purely heuristic - although both of them can be confirmed by experiments) descriptions of engineering systems allow for formal analysis: to find errors without creating a system, and often to calculate the necessary or optimal characteristics of the system. The very expensive method of trial and error with its endless cycle of guesses and experiments with the help of formal descriptions turns into a completely different method of work, the number of trials becomes several times less. Science is the source of useful formalisms (methods for describing various phenomena). The number of formalizations is growing, the number of found heuristics is also growing, so the level of engineering grows over time.
In this regard, any achievements in engineering proposed by Billy Koen should be assessed not on an absolute scale, but at a specific point in time, in accordance with the amount of scientific and heuristic engineering knowledge accumulated at that moment - and this “current state of engineering” Billy Koen proposed to call SoTA (state-of-the-art). An engineering project is bad if it does not use the full completeness of scientific and heuristic knowledge accumulated at a particular point in time. Over time, the volume of knowledge grows, and engineering projects become more and more complex, reaching characteristics that were impossible for the previous time.
Science as “teaching birds to fly”
There is an opinion that science is useless for practical activity. Practitioners succeed not on the basis of scientific knowledge, but on the basis of “tinkering” (cf. “He is tinkering with a car” - “he fiddles with a car”).
This point of view was developed in the book by Nasim Taleb "Antifragility". He compares scientists to those who come to birds and try to teach them to fly, giving knowledge of aerodynamics. A typical statement in his book on this topic: "No one fears that a child who has no idea about various theorems in the field of aerodynamics and is unable to solve the equation of motion, will not be able to ride a bicycle." It protects trial and error, protects heuristics. He's absolutely right. And he is right when he writes about the creation of jet engines: at first there was a lot of trial and error, then only the theory appeared, and not vice versa.
However, research gives us a way to think in new ways: more mindful, faster, and more reliable. Not that research allows us to think at all. We think without them, but spontaneously, slowly and not too reliably. Trial and error is good for everyone, except it is extremely expensive and time consuming. If there is a way to briefly describe something physical, and then work with this description-model, and not with the physical object itself, then this should be done. If you teach a child to ride a bike, then you do not need special science. And if you teach a computer to be an autopilot on a jet plane, you will ruin too many jet planes by a trial and error method that is unclouded by science.
Another argument for science and compact descriptions comes when you notice that Taleb's books don't say anything about teamwork. When we are not talking about a market where there is “long-distance interaction” (no one knows each other, transactions between strangers) and where Taleb's reasoning works well, but when we want to transfer good thinking to someone else, but do not understand what it is from thinking is what to convey. Hunting and gathering talented people is good, but the transition to sedentary agriculture gives a jump in labor productivity - it is cheaper to grow talent than to find them.
So first we need some kind of science in order to describe engineering knowledge compactly - and only after that we can transfer it.
Another aspect of engineering work is that it is not done alone. Coordination of efforts of hundreds, thousands and even tens of thousands of people is needed. All these people must somehow agree with each other. How can they agree, if everyone can tell about their part of the case about the same as a boy riding a bicycle about his ride “I feel like I’m keeping my balance and I feel like I should bend down at high speed”? We need compact descriptions so that people can have the same description of what they are doing, so that there is no problem of building the Tower of Babel.
The approach to systems engineering thinking and action outlined in our book is completely unnecessary for lone engineers, among lonely there is always Kulibin or Lefty. But if we are talking about some more or less large-scale collective engineering activity, then synchronizing the ways of discussing the project can save a lot, a lot of time - after all, everyone remembers the problem that arose during the construction of the Tower of Babel? We must learn to describe to other people what we are doing and why so that other people can join us.
Of course, being able to describe something both in engineering and in management (and even in literature) does not mean at all that you will describe something valuable and important. Graphomaniacs will never get the Booker Prize, although they can write. Learning to think about architecture or a project proposal, learning to write down your thoughts in a compact "science" does not mean that you will come up with something interesting. “Think and think” in this respect is similar to “teach and learn”, “do and do” - the process is nothing, the result is everything. But if you do not think, then you will not come up with. If you don't teach, you won't learn. If you don't, then you won't. The process is important, without it there will be no result.
So first we need engineering science, although we know for sure that engineering ("engineering", as they say more and more now) is not a science. But we need compact descriptions of engineering and management at least in order to negotiate engineering and management with other people.
