Chapter 5: Engineering Thinking

by Jonathan Y. H. Sim


Allow me to begin this chapter with a rather perculiar question: Why is it that we humans put people on the moon first before we figured out it was a good idea to put wheels on luggages?

In other words, why didn’t we put wheels on luggages earlier? Luggages have been around ever since the 16th century. So why was there such a long delay?

This might seem like a nonsensical question, but there is something rather profound about it that we rarely think about.


1. The Co-evolution of Technology and Society

You might have heard about how inventions change the world. Every new piece of technology opens up new pathways of possibilities for what we can do, new possibilities for what we need (or want), and new possibilities for what we can create.

Yet, it seems rather odd that luggages have been around since the 16th century, and no one thought to put wheels on it until the 21st century (a few months after we sent humans to the moon). It’s not like wheels weren’t invented in the 16th century. Wheels were widely used in carts and carriages. So why didn’t humans think about putting wheels on luggages until much later?

We need to understand that two things happened when we sent humans to the moon. First and foremost, the very act of sending someone to the moon was an event that changed people’s perceptions of the world. The event was symbolic of the possibilities that we can travel to anywhere in the world anytime we like. The sky’s the limits and humanity has finally surpassed it. What is there to stop us? If we can travel to the moon in an incredibly short span of time, we can travel anywhere around the world. The event changed our perception of distance. We’re not as far as we thought we were. This in turn led to an increased demand for travel.

Second, the technological developments involved in putting a human on the moon contributed to several developments in transportation, manufacturing, and many other sectors. These allowed engineers to meet the demand for increased travel by producing faster transportation solutions. Trains, boats, and planes got faster and could accomodate more people. Not only did it meet the demand for more travel, it generated even more demand for travel. And in that short span of a few months, it became apparent to many that wheel-less luggages were a hassle for travel. And this was what led ultimately to someone deciding to put wheels on it to solve the problem.

Inventions change the world. Every new piece of technology changes human society, and that in turn generates more technological change. But we are often too inclined to think that it’s only the big inventions that change the world. That is a mistake! Even the smallest inventions like chopsticks, tables, and chairs, can vastly change societies and cultures more profoundly than we can ever imagine. These seemingly mundane things exert as much, if not more, influence in changing our needs and wants, and how we organise ourselves and how we interact with one another.

The historian, Q. Edward Wang, has a very interesting book about the history of chopsticks. Because of the incredibly cold climate, the ancient Chinese had a preference for piping hot foods. Thousands of years ago, they used to eat with a spoon-like device that could also double off as a knife. But as their preference for hot foods continued, they eventually learnt to use sticks in handling meats and vegetables inside the hot soups and stews. And over the years, the Chinese came to develop the use of chopsticks as the preferred tool for eating hot foods.

But as chopsticks became mainstream, another interesting phenomenon happened. The ancient Chinese people began changing the way they cooked. Since chopsticks became the preferred utensil of choice, they preferred to prepare their ingredients in ways that made it easier to eat with a pair of chopsticks. Hence, they started cutting ingredients into small pieces so that one could eat without a knife. And they began to prefer stewing meats longer than before so that the meat could fall off the bone without much effort. From a culinary standpoint, that was a major shift in the way the ancient Chinese prepared and ate their food.

In contrast, cultures that don’t use chopstics generally prefer food to be less hot. Cultures that use hands to eat generally prefer foods to be at room temperature, or at least warm enough so that one could eat with one’s hands without burning them.

One other interesting bit from the book was how the introduction of Western style tables into China changed the way people ate as a family. Before Western-style tables entered the picture, Chinese people used to eat sitting on the floor (like many other Asian cultures). There was no sharing of food because it was just too troublesome and unglamorous to get up from the floor to take food from someone else. So dishes were always prepared for individuals. But when Western-style tables entered China, a new social phenomenon entered the scene. People began to sit around tables to eat because it was easy to share food with one another. This led to the creation of dishes that were placed in the middle of the table, so that they could be shared by others.

Something as simple and mundane as a table led to the creation of a new social norm, and a new cultural activity!

This is the co-evolution of technology and society. With every new technological solution, society changes. Sometimes the changes are subtle, sometimes the changes are significant. But whatever it is, with every change brought about by technology, there is always a new set of problems waiting to be solved, and new societal arrangements.

Today, more than ever, technology has a very strong presence in our lives in the way we socialise, relate, and do business with each other. It is for this reason that it is all the more essential for us to approach engineering and other technological problems from a more holistic perspective. We must recognise that these days, engineering and other technological problems are not just purely technical problems. Yes, there is the technical aspect, but it can impact societies in more ways that we can imagine, and so we must be extra careful in the way we approach and solve problems.

If chopsticks and tables can change societies and cultures so much, what more could new technological tools do to change us? Whether it is for the better or for the worse, it is worthwhile to consider what technology is doing to societies, and what we’re doing with it.


2. Problem Specification

Before one can solve the problem, one must first have an understanding of the problem. But there are different ways to solve a problem. Engineers tend to approach problems by translating the problems into deliverable goals. This process is known as problem specification.

Imagine you are an engineer assigned to solve a famine crisis. The first thing you need to do is to specify the problem that you’ll need to solve. The problem is that the people of Hungeria have no food. Of course the solution is to give them food. But this is a very vague understanding. How exactly should we give food to them? What is the best way to provide food?

As an engineer, we can translate the food problem into specific deliverable goals. First, we need food that’s easy to transport; the food needs to be cheap so that we can buy massive quantities without spending too much; it needs to have a long shelf-life so that we can make a one-time delivery without worrying about food expiring; and it needs to be easy to prepare so that hungry people (who have no energy) can get their much needed nutrition.

Sounds good? So based on the specification, what solution fits this criteria? It’s obviously canned food, but what kind of canned food. If you take a trip down to the supermarket and check every canned food on the shelves, you’ll discover that the answer is canned beans!

But let’s think about this solution for a minute. Is it sensible to send an entire cargo ship worth of canned beans to the starving people of Hungeria? If you are experiencing famine, would you be very happy to eat nothing but beans for breakfast, lunch, dinner, every day for months? Absolutely not! Even if you were given a variety of beans, you’d still hate it.

From an engineering perspective, it would seem that we have solved the problem. In that regard, you are not wrong. You specified the problem and you solved it with canned beans. It’s the perfect solution based on the specification. The problem is that the problem wasn’t specified well enough! And this is, in many ways, one of the major flaws in many engineering solutions that involve humans. We tend to be so good about understanding and specifiying deliverable goals for technical issues that we can forget that humans are more than machines. We can’t eat canned beans every day for the rest months. We need more than that.

But in many ways, this reflects precisely the problem that we have when it comes to problem solving. Many of us are very impatient people. We don’t like to sit around and think long and hard about problems in order to understand them well. We prefer to be doing things, and fixing problems. And in many ways that is the problem with a lot of solutions around us. We are coming up with solutions for problems that are poorly understood.


3. Engineering as Applied Philosophy?

It is common to think that engineering is more a science than an art. After all, engineers work with a lot of equations, algorithms, models, and simulations. But I think it’s worthwhile to recognise that there is a philosophical aspect to engineering, and that involves determining what counts as the optimum balance between the ideals and the constraints of the imperfect real world when trying to satisfy the specifications of the problem. It is rare to find a solution that meets every specification of the problem perfectly.

The art of engineering involves having to manage problems that are multi-dimensional in nature. The act of seeking that optimal solution in the face of all the necessary compromises is itself an art. Making something cheaper will inevitably affect several other factors at the same time, and similarly, making something safer will yield other undesirable effects (like more expensive, or harder to maintain, etc.). In many ways, I like to think of this as a kind of applied philosophy.

The quest for an optimal solution is therefore one that requires a lot of judgement and debate, and that is, once again, strongly influenced by the understanding of the problem. It is easy to forget that these issues exists when we deal with lots of numbers. But we must remember that there is meaning and sense behind the numbers and figures we employ.

There are two key concepts engineers use to determine the optimal solution. They are: (1) over-design, and (2) under-design. These concepts help us to better understand how much of something we need, and what we can compromise in the face of other needs/requirements. By attempting to avoid over- and under-designing solutions, engineers can find the right balance to those multi-dimensional problems.

It is important to note that what counts as over- or under-design revolves around the understanding of a problem. In the old days, furniture were expensive to produce. So people typically made them to last for many generations. If you owned a really old chair or bookshelf, you could hand it down to the next generation, and the generation after, and it would still last as well. These days, nobody wants to keep furniture around for that long. Most people are happy to replace furniture that’s about five years old. Making a chair that can last a hundred years would be over-design. It’s too expensive and far beyond the needs of consumers. But if you were to produce a chair that lasts for six months, it would be considered under-design as its lifespan is far too short.

But lifespan is just one perspective to question whether something is over- or under-designed. There are many other issues ranging from cost restrictions (is it a budget chair or a luxury chair), to other techincal issues like the strength of the chair, e.g. how much weight should a chair be able to hold up? If you are designing a luxury chair that costs a lot of money, you can afford to over-design it to hold up the weight of two or three sumo wrestlers. But if you are designing one of those cheap budget chairs to be sold at the $2 shop, you are under a lot more constraints. Must the chair hold up the weight of three sumo wrestlers? Well, that depends on the typical profile of customers at the $2 shop. Do they tend to be sumo sized? How frequently do they abuse chairs? If they are buying from a $2 shop there is a certain expectation that chairs will be of a certain compromised quality that people are willing to embrace. In which case, it would be fine to reduce the quality of the design. Maybe two sumo wrestlers might be too much, so maybe the weight of one sumo wrestler will suffice. Should we produce a chair that can withstannd the weight of half a sumo wrestler? That might be risky. You don’t know the typical weight profile of your customers. You only know that they are certainly less than sumo-sized. So maybe sumo-size might be enough to withstand additional weights that may be applied onto the chair.

This was just an illustration, but I hope it shines some light on just how the concerns of over- and under-design shift with the understanding of a problem. More than just about solving problems, it is important for engineers to have a clear understanding of the problem and what is required before they can decide what counts as an optimal solution for bridging ideals with the imperfect world.


4. How do you Expect the Unexpected?

It is the engineer’s job to ensure the safety of its users. There is nothing more dreadful than to see your creation fail so spectacularly that people die in the process. Yet, despite all the efforts that engineers put in to ensure safety, failure sometimes seems unavoidable. Engineering failures can lead to a range of consequences. We’ve seen some of these in recent news, like the Samsung Galaxy Note 7 battery exploding in people’s pockets, Takashi’s car airbags exploding during car accidents releasing shrapnel into the bodies of people sitting at the front of the car, buildings and bridges collapsing, nuclear power plants leaking nuclear radiation, and of course, the regular breakdowns of our MRTs, etc.

Sure, some of these failures are indeed due to negligence, error, or even the lack of ethics, where companies try to squeeze greater profits instead of focusing on increasing the safety of its users.

But what about the ones where engineers have done their very best, and yet failure still occurs? It’s always easy to point the finger at engineers and claim that they were negligent. In some cases, this is due to hindsight bias, where we now have the clarity of hindsight to see what the engineer couldn’t see at all.

But imagine that you are the engineer designing the system or product before the tragedy happened. How do you know that you’ve done your best, that you have exhausted every possible means to prepare for all that you know as well as for all that you don’t know? How do you know that you have done enough to ensure the safety of hundreds or thousands of lives that you can sleep well at night? How do you expect the unnexpected?

The problem is not as easy as it seems. We can only model and test scenarios based on what we know (known knowns), and we can only use scientific theories to predict the things we know that we don’t know (known unknowns). There is nothing in our intellectual tools that allow us to prepare or expect the unknown.

There are two kinds of unknown that are particularly worrying. The first are the unknown knowns (I don’t know that I know). These are cases that we should have known, should have expected, or should have prepared for. Yet, we are blinded by biases from ever recognising that it could ever happen. All sorts of biases could be at play. It could be confirmation bias (where we seek to confirm our belief, instead of seeking to find ways where we could be wrong), it could also be survivor bias (where we don’t realise that we are only looking at an unrepresentatie sample that made it through a selection process.

The second kind of unknowns are the unknown unknowns (I don’t know that I don’t know). These are things that are way beyond what we ever know. They exist as outliers beyond the realm of what we know, beyond what our scientific theories and models are capable of detecting.

The philosopher, Nassim Taleb, refers to these kinds of unknown events as “Black Swan” events. He defines them as unexpected catastrophic events beyond what we know. These dangers stem from a lack of knowledge (either because we simply don’t know enough, or are blinded by bias). Since these black swan events remain quite unknown to us, it is also almost impossible to imagine just how disastrous their effects will be. And for this reason, people tend to downplay the weight of these events.

What makes black swan events so scary isn’t just that we cannot predict them. Rather, the impact is made worse by the fact that because it’s something so new, so alien to our normal understanding of the world, we don’t know how to make sense of it when finally happens. It took us a long while to be able to make sense of the terrorist attacks of September 11, when terrorists crashed two planes into the World Trade Centre. It breeds a lot of irrational responses as a result. It is only after a long time since it happened that we’re now able to make sense of it, and while subsequent attacks are still surprising and scary, it doesn’t create the same psychological confusion that the first event made.

It is worth noting that Taleb chose to name these events “black swans” to pay tribute to the shock Europeans had when they first discovered black swans. You see, for centuries, Europeans had only seen white swans. And because they only ever witnessed white swans, they came to have a strongly held belief that swans could not be any other colour but white. But let’s think about this for a moment. Why should your belief be so strong just because you have never seen any disconfirming evidence? The improbable is not the impossible. And for that matter, all our scientific theories are only tentatively true. They are right until the very day we find something wrong with it. So why should the colour of swans (or any other belief about the world) ever arrive at 100% certainty?

So, you can imagine how mind blown the Europeans were when they first came to Australia and saw black swans for the first time. It was a discovery that shocked all of Europe. What is interesting is that even in the face of empirical evidence, there were some who continued to hold firmly to the belief that swans can only be white that they refused to accept that swans could be black.

This in many ways resemble the unknown. Complacency sets in when we hold on to firmly held beliefs about the things we do. So we only do our best for what we know thinking that what we know can never go wrong.

What are some examples of engineering failures due to black swan events? Well, one good example is the Titanic. Going by the engineering standards of its time, it was regarded as unsinkable. But we must remember that the engineering standards of unsinkability are based on what engineers knew about known causes of sinking at that time. People had taken for granted that a ship could sink due to other unknown reasons.

Another example would be the Tide Pod laundry capsules. These are capsules containing washing detergent that people throw into washing machines. When it first came out, parents complained that it looked so much like candy and children could mistakenly put it into their mouths. Yet the people in charge argued that it would be so improbable. People aren’t that stupid as to eat laundry detergent pods. But it did happen once in 2012. And again at the start of 2018 when an Internet challenge came out asking children to film themselves eating such pods in order to become famous online. This was a case of inaction due to a firmly held belief that it wouldn’t happen.

Black swan events are largely knowledge problems. Many of which are due to biases preventing us from recognising the possibility of it ever happening. So is there some way that we can determine whether we are being biased or not?


5. How Probable are Improbable Events?

Imagine you are the chief engineer of a car company. You recently engineered a family car that has since been launched in the market. It’s your best design so far. It is safe enough to go on the road, and performs well enough for most consumers.

However, one day, a customer returns one of these to your workshop, but it is damaged. A jackfruit had fallen from the sky and created a huge and deep dent on the roof of the car. The driver and the passenger are safe, but the driver argues that the car is not safe enough. Your boss feels inclined to side with the driver, but he wants you, as the chief engineer, to make an assessment annd propose the next course of action.

Which of the following would you do?

(a) Propose to do absolutely nothing since the likelihood of a jackfruit dropping on a car is so low, that driver is just very lucky/unlucky to have that happened to him. It’s so improbable it won’t happen again.

(b) Propose to enhance the strength of the car’s roof to safeguard against any similar repeated events?

(Please choose one of the options above before you continue.)

You probably chose Option A, didn’t you? And your reason is that it’s so improbable that it won’t happen, right?

After all, when was the last time you heard of a jackfruit dropping on a car to such an extent that it would leave a huge dent? How often do you hear of car incidents like this?

My question for you is: why are you so certain that this is an improbable event? How sure are you that it’s improbable? We tend to wrongly classify a lot of events as improbable for various reasons. E.g. we don’t hear or see enough of it happening, or we have made wrong assumptions about the cause of the event, and so we assume it to be more improbable than it really is.

People say that lightning doesn’t strike the same place twice. Most of us are inclined to believe this because we ourselves have never observed lightning striking the same place twice. But this is like a black swan event. Just because you didn’t see black swans doesn’t mean they don’t exist. In fact, there’s a lot of scientific evidence that found lightning striking the same place more than once. In some cases, lightning can strike the same place about 20 times within a single storm.

So, how do you know whether you’re right with your assessment? Just because you don’t hear another customer complaint or read the news about a traffic fatality does not mean that you’re assessment is right. Maybe many other customers had encountered something similar or worse, but didn’t dare or bother to report such cases to you. Or maybe, it’s just a high fatality event that will happen soon enough?

Whenever we face such seemingly improbable events, we can be blinded by biases that hinder us from making the necessary changes or preparation. One such bias that tends to occur in this context is known as Normality Bias, which is a belief that causes people to underestimate both the likelihood of a disaster, and the severity of its effects if it were to happen.

If you were quick to conclude that the jackfruit case was quite unlikely, chances are, you were operating under the influence of Normality Bias. We fall prey to this bias quite easily because things tends to behave normally around us most of the time, and so we expect things to continue to function normally even in cases where things tend not to behave as normally as we would expect.

What I would like to do is to introduce you to five heuristics that you can use to quickly assess whether an event is more probable than you think. Basically, if we are to dismiss a case as improbable, we must have solid reasons for it other than just stating that it’s improbable because we have not heard it happen before. Biases have that effect of making us certain about issues even when there is no solid justification for it. This five heuristics will give you a way to evaluate and justify them.

The statistician, David Hand, argues that the improbable occurs more frequently than we think. Improbable events are not impossible. They can and do occur from time to time. And their likelihood increases dramatically when more than one of the following improbable principles are true:

(1) The Law of Inevitability states that something will inevitably happen given. As long as you park your car under a tree, it is inevitable that something will fall from the tree onto your car. It could be a leaf, it could be a branch. Or it could be a giant jackfruit.

(2) The Law of Truly Large Numbers states that if you have a sufficiently large number of opportunities, improbable events will be unavoidable. The chances of a jackfruit falling on a car are very slim (let’s say it’s 0.00001%). But if you have millions of cars parked under jackfruit trees, the laws of probability states that we can expect that at least 10 cars will be hit by a jackfruit. This is an outcome that is statistically unavoidable.

(3) The Law of Selection states that the seeming improbability of an event could have been subject to a biased sampling or a selection process. E.g. a hundred and one things must have fallen and damaged cars. But we don’t know about this because either: (1) people don’t see a point in reporting the incident (i.e. under-reporting of faults); (2) most of the things that fell and damaged cars are not newsworthy (and so go unreported, so we get the impression that it’s unlikely); or (3) the people who forward the cases to you (the chief engineer) feel that these cases are not worthwhile to think about. There may have been other selection processes happening behind the scenes that we aren’t aware of. But whatever they may be, these processes are making the probable seem rather improbable to us.

(4) The Law of the Probability Lever states that changes in circumstances, even the most minor, can drastically affect the probabilities of the event. So our assumptions about the cause of the event can alter the probability of it happening. A random jackfruit falling on a poor guy’s car might seem like a very improbable independent event. However, if the region happens to have a lot of jackfruit trees, this raises the probability of damage by jackfruits. And if climate change is generating a lot of heavy storms in the area, the probability of damage by jackfruits would greatly increase because the rain and wind would increase the odds of jackfruits detaching from trees onto cars.

(5) The Law of Near Enough states that we should regard similar events as identical. Sure, a jackfruit damaging a car might seem like a one-off incident. But there are many other things that can fall from the sky (or trees) with a weight similar to or heavier than jackfruits, e.g. branches, logs, rocks from nearby cliffs. These will cause the same kind of damage or worse. Once we factor these into the equation, the probability of car roof damage will increase, and it will not be as improbable as it seems.

When we examine improbable events with these five heuristics, we’d come to realise that a lot of improbable events shouldn’t surprise us – they are bound to happen, and they are a lot more probable than we initially thought they would be. And if they are more probable, then the onus is on the engineer to do what is necessary to prepare for such events if they should happen.

So, before we dismiss anything as improbable, we should check our beliefs and question where got that certainty about it being improbable. The absence of evidence is not the evidence of absence. You might just be the lucky one who didn’t get to observe the event happening more regularly.


6. Dealing with the Unknown by Building Robust Systems

Thus far, we’ve talked about how to deal with expected failures, including improbable ones. But how do we prepare for what we don’t know that we don’t know, for the unknown unknowns?

On this matter, Taleb argues that we need to build robust systems!

There are three concepts that engineers use to build robust systems. They are: (1) iterative revision, (2) safety factor, and (3) redundancy.

(1) Iterative revision is not unique to engineering. It’s basically a process of learning through failure that we find in many other disciplines. Good systems (or organisations) have in place a means for quickly learning and correcting faults that come up along the way. A good example will be the system of after-sales care for many of the technological things we use. iPhones and cars are good examples. There is a system in place for engineers to learn the many ways which we have messed up our devices whenever we bring them in for repairs, and they will then learn and implement the fixes in subsequent versions.

(2) Safety factor concerns questions of durability. How much do you want to over-design something to withstand situations that you cannot predict? In the ideal world, we would like it to be as strong as possible. But that comes at a huge costs. So if we definitely cannot choose either ends of the spectrum (one end being “no safety” and the other end being “extreme safety”), how then do we decide what is the best option?

In cases like this, engineers tend to choose the safety factor by designing for the worst case scenario (where worst is defined as a probable worst case scenario that makes financial sense). For example, Japanese civil engineers construct buildings to withstand not only the most common type of mild earthquakes, but also some of the more severe earthquakes that occur once every 500 years. No one really knows when such an earthquake would occur, but if it can withstand something as bad as a once in 500 years earthquake, it can withstand a lot of other unforeseen and unexpected seismic activity.

One might ask, why not go further and design buildings that can withstand the most disastrous earthquake that occurs once every thousand years? Such a design would cost far too much for it to make any economic sense to develop a solution. But of course, if failures begin to show despite designing for the worse case scenario, then it is imperative to learn from the failure and make the necessary revisions in the next iteration of design.

(3) Redundancy is the last of the three concepts for building robust systems, and this is one that Taleb goes to great lengths to discuss. He refers to redundancy as a kind of insurance, or important back-ups for when things go bad. Nature is full of redundant systems. The human body for example, has two eyes, two lungs, two kidneys, two brains, etc. Similarly systems should have some amount of redundancies. One may not be enough.

Let us take the example of a ship. Ships have redundancy electrical generators. One may not be enough. It could fail out at sea, and no one will be able to radio for help. Two may not be enough either. If both were to be in the same location, a fire could destroy both generators. One could add a third generator in a location away from the first two. That way if a fire broke out, we still have a third generator working fine. Of course, one could ask: why stop at three? Why not go for four, five, or six generators? Well, that would depend largely on the purpose of the ship and whether it is a cost effective solution.

However, with every generator one adds to the ship, or with every effort made to increase the safety factor of a ship, we introduce inefficiencies. The ship gets heavier, and so it cannot move as fast as it should, or it might have to consume more fuel, making it more costly to travel.

This highlights the tension between robustness and performance. In this imperfect physical world, we are constrained by the two. The more we seek performance, the more we must sacrifice on robustness, and vice versa. We often cannot have it both ways.

One good example would be the story of armour in history. In ancient times, weapons weren’t so sharp, so the people who built armour could favour performance over robustness. But as weapons grew sharper and sharper, preference shifted to robustness. And armour grew thicker and thicker over the centuries. But when the armour grew so thick that bullets couldn’t go through, the opposing forces decided to use weapons that could concuss the enemy instead. Since the enemy cannot move fast, it is perfectly fine to use weapons that are incredible heavy to smash their brains out. They can’t run anyway. This led to the invention of clubs and maces in medieval warfare. When more and more soldiers died because they couldn’t run, the people who built armour shifted their preference to favour performance over robustness. And by the 1600s, soldiers wore signinficantly less armour.

Without a doubt, engineering deals a lot with numbers and graphs, with equations and models. But these are only to support the philosophical side of engineering, which is about seeking the optimal balance to meet the specifications of a problem. This is an incredible feat, and it is one that has drastically changed and continues to change the lives of humanity.