Don't get caught in the incident pit

The incident pit is a concept I first read about in one of my mums diving magazines. At that time I realised how useful it is in describing incidents involving divers and how a lot of small things going wrong can result in a major incident.

In essence, the incident pit is something that you gradually fall into. One small thing might not initially go to plan or a relatively minor piece of equipment might break down or get left at home; when this happens you have put your first foot into the incident pit. Initially it is not a problem, but then something else goes wrong - that is another step into the pit. The challenge with the incident pit is that with each step, not only do you get closer and closer to the bottom of the pit and a serious incident, but with each step the sides of the pit get steeper and steeper. It gets more and more difficult to get out the further into the pit you go.

I think there is something to learn from this concept for engineers. I often see engineers taking steps into the incident pit with relatively minor problems, potentially causing much larger problems in the future. To define the incident pit I think that there needs to be two key elements. The first is that the incident pit is caused by a series of problems, any of which would not be a problem on their own, but each one exacerbates the next. The second is that you have to be in a situation where you are incrementally committing yourself. For divers this is relatively easy to understand, the deeper you are diving the more committed you are and the more difficult it will be to solve any problems. I think this is often the case for engineers; as we design and build something, we make more and more commitments and we have more and more invested in something, so just stepping away becomes difficult, if not impossible.

The trick is to know when to stop taking steps into the pit. Another key feature of the pit for divers is that you can always choose to stop taking steps into the pit, but this has a cost, because their dive may have to be cut short. It is the same in engineering, if you choose to stop taking steps into the pit there will probably be a cost.

I want to look at how the incident pits forms in engineering, so I'm going to consider a simple building being designed by a structural engineer. The design starts off well with no major problems and he makes his first submission to the client. They love the design, especially the huge front window that you have given them. At this point you haven't taken a step into the incident pit as nothing has gone wrong, but you have started to get committed.

The next day you get a call from the manufactures of the glass for the centrepiece window. They are no longer able to provide glass quite up to the specification you wanted. This is the first step into the pit. It might not be the designers fault but he does have the choice of whether to continue or not. At this point in time it is not a major problem, even if the glass is not quite up to the expected specification, it should still be strong enough so the engineer chooses to continue.

So the engineer goes and makes a few more submissions to district planners, the contractors who are pricing the project, and utility companies to check the sewers running under the house will be okay. As each one of the submissions goes in, the engineer gets more and more committed to the proposal; backing out gets more and more difficult.

And whilst the project is getting more and more committed, problems keep affecting the large glass window. The original calculations needed to be modified slightly imposing greater forces on the window, new codes of practise are issued which require a better performance of the window, the structural frame has to be modified slightly increasing the span of the window. The engineer is getting caught in the incident pit as he gets more and more committed. The small problems gradually mount up and if the engineer does not pull out soon enough he will be trapped - the design will not be adequate, but too many commitments have been made. All of a sudden the small problems escalate into one big problem.

There is no easy way to deal with the incident pit. You just have to recognise when things are not going as planned and know when it is time to pull out so you don't get trapped. By remembering how these small problems escalate and how easily you can get trapped, it is easier to deal with the problems.

Sir Ken Robinson: Do schools kill creativity?

In an entertaining talk by a leading thinker, Sir Ken Robinson proposes that creativity is being killed by the education system.

Creativity in engineering

Creativity is probably one of the less well recognised abilities that all engineers have. Solving practical problems is what engineering is all about and if you are trying to solve a problem that has never been solved before, you have to think creatively to come up with the solution.

The conventional view of creativity is that the fewer boundaries there are, the more creative the solution. This is however quite profoundly wrong in the case of engineering a solution to a problem, for engineers it is boundaries that allow us to use our creativity.

To demonstrate this I want to consider the case of somebody who asks an engineer to design a bridge from an island to the mainland. The engineer is only too happy to oblige and starts to scratch his head to come up with a design. So what design should he come up with? The engineer doesn't know much about his client or his problem, but does want to please him. So what is the best solution?

I'm going to simplify this problem somewhat to consider it in detail. I want to consider the bridge solution in terms of only two variables, the capital cost of the bridge and the capacity of the bridge, this is just to simplify the model we are going to consider, and more complex models will be developed later.

To model the solution I want to consider a two dimensional solution space. Each dimension represents one of the solution variables, so in this case we have a two dimensional space with one dimension representing the capital cost and the other dimension representing the capacity of the bridge.

Having generated this solution space, we need to consider the original request, a bridge to connect an island to the mainland. We don't know anything else so the best way to get as close as possible to the clients request is to go for something in the middle of the solution space, something average. In this case it probably represents a bridge with two lanes in each direction, something fairly standard and not very creative. If we go for a creative solution, something further from the middle of our solution space, we run the risk of being a long way from the clients requirements.

So how do we come up with something creative? What if we asked the client a few questions, one relating to each dimension of the solution space. What would you like the capital cost to be? What would you like the capacity of the bridge to be?

By asking these questions we can find the point on the solution space that represents our clients aspirations. But how does this relate to creativity, instead of having the whole solution space to use to come up with our bridge design, we only have a small part of the space to work with.

Consider what would have happened if our client had asked for a very low capital cost and a very low capacity because our client only needs to cross to the mainland on his own once a week. In this case, it seems like he doesn't actually want a bridge, because a rowing boat is a better solution. Just because we are tied to a small region within the solution space, it doesn't mean that our solution can not be creative; such as proposing a rowing boat instead of a bridge.

Exploring the different points within the solution space shows us the range of solutions that could be develop for this simple request for a bridge. Most of these solutions could not realistically be proposed without some initial input from the client to allow us to come up with the creative solutions for a point in the solution space.

Using this example it is clear that creativity in engineering and problem solving is not necessarily a result of starting with a blank sheet of paper and an open brief. It is the boundaries that are imposed on our solutions that both allow us and force us to generate a creative solution. I believe that many engineers do not like getting a full brief either because of the perceived difficulty in coming up with a solution with a very tightly defined solution space, or because they wish to have a broad solution space so they can look at many solutions.

This approach goes totally against what it means to be an engineer. We should be aiming to exceed our clients aspiration, and the only way to achieve this is through knowing where a clients desired solution is on the solution space. We should be embracing the challenges that we are set. Of course we must also have the tools to come up with the creative solutions that sit within a well defined solution space, and this is where engineers need to be taught design skills. It is these design skills that form our toolbox for coming up with creative and novel solutions.

Engineering hints and tips

This blog did not seem like the right place to put some real hints and tips for engineering design so I've set up a separate blog to cover these (Engineering hints and tips)

The background to numerical models

'How important is it to understand how a numerical analysis programme works in order to use it for design?'. I guess if you asked any engineer this question the answer would always be very. But if we asked if those same engineers understand the analysis programmes that they use for design, we might get the answer no more often than I think we would find comfortable. It's an uncomfortable truth about the industry we work in.

When I ask myself the question why this should be the case I personally can't come up with one answer. One obvious reason would be that so many users are self taught when using analysis programmes. The documentation, especially covering the theory, is often poor and as usual the training of the user is also limited if it actually exists at all. Learning the theory behind a program is often very difficult and can be very mathematical..... but that doesn't mean you have to learn this hard maths to understand how a program works.

To prove this I want to consider a numerical analysis programme called UDEC (ref 1.). This is a very powerful tool, typically used for analysing two dimension rock mechanics problems such as rock slopes or tunnels in rock. The image shows a typical analysis of a tunnel in rock showing how the programme can analyse complex joint patterns in the rock around the excavation. So how does it actually work?

Rather than quoting the extensive manual, going into the finite difference method in detail I am going to give a very quick and dirty explanation of how it solves the problem. The solution method used by UDEC is basically to apply Newton's laws of motion to each block, zone or other structure within the model. From this an acceleration can be determined for each element. By considering very small time steps the gradually movement and straining of each part of the model can be calculated. Once the small movements and strains have been calculated for one time step, the resulting small changes in the contact stresses, stresses within blocks and any other forces on the model can be calculated. These forces can then be applied to the elements within the model and the acceleration and displacement can be calculated for the next time step. The model steps through time slowly until a solution is reached i.e. the out of balance forces within the model tend to zero.

That is all there is to it. It doesn't mean if you know this, you are ready to use the programme in anger. There is a lot more theory to learn, but that theory doesn't have to be mathematical. The problem is that it is finding non-mathematical explanations of the theory is difficult. If we can get more explanations of how things work without being too mathematical I can only see this as being a positive.

If you have any explanations for how things work or find any please post them here so that we can all improve our understanding of the tools we use.

Ref 1 - UDEC (Universal Distinct Element Code), HC Itasca