My commitment to the real world

The more I write in this blog, the more I realise what is important. I called it engineering for the real world, but now I realise the emphasis should be more on the real world and less on the engineering. I am an engineer and I think like an engineer but what I want to write about is the real world, the world that we all live in, for better or worse.

A few years ago I watched a documentary on how soilders are trained. The premise of the film was that most people do not have a natural instinct for killing, they have to be trained to do so. And the training that a soldier has to go through to create the natural killer instinct fundamentally changes the people that they are.

Of course, all this training must come at a price, and for soldiers it is a heavy one. The training does have an effect on who you are as a person and more importantly what your natural reaction to a situation is. This is by no means exclusive to the military, intense training affects us all as people. Many recruits probably don't realise this, but by agreeing to train as soldiers, they are making a huge sacrifise, not just potentially their lives, but they are allowing their nation to turn them into machines of war and in doing so change who they are as a person. It is of course not all negative, there are many benefits to becoming a soldier, but for those who have not been in the military I think it is important we remember all of the sacrifises that soldiers and their families make to protect our nations. Since watching the documentary I have always supported soldiers no matter what my view of the conflict they are engaged in, because of the sacrifise that they have made.

This morning I watched a TED talk by Deborah Scranton. She is a documentary film maker who has been creating a film covering the conflict in Iraq. This talk made me realise something, I have always said that I have supported soldiers, but to say something, and to make the commitment to do something are two different things. It is so easy to be a well meaning person saying that you believe strongly in this and that, but does this actually mean something unless you actually do something about it. It might not have to be something particularly special or important, but I think only by doing something can we demonstrate our commitment.

I feel now that I need to go out and do something for returning soldiers. It might not be much, but I have to demonstrate my commitment to myself, I have to find out if I am truly committed or if I need to reassess the way that I view the army and the people who work within it.

The talk by Deborah is really compelling. I'm not going to discuss the rights and wrongs of the wars going on around the world, but this is a film that is worth looking at for everyone. Whatever your point of view it does demonstrate what the soldiers are going through, and if demonstration is ever needed that soldiers in a conflict zone are not just doing their job, this film is it. It is a cliché, but this talk is so compelling that the silence is deafening.

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.

Pangea day

I've often been struck by the power of films. Very few other methods of communication seem to have the same ability to touch me. I think this might be because of the unique combination of story, images, music and words that a film can have. A well done film is a powerful thing and that power has to be used carefully.

I see Pangea Day as potentially one of the most important days in the history of humanity. The power of the films could profoundly change the way the world works and the way that we interact with our planet.

If you want to get involved I would encourage you to take a look at another film. This is the original wish by Jehane Noujaim, given to the TED conference.I hope that many more wishes like this have a chance to come true.

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.

Rotherwas Ribbon

It takes a lot to hold up a bulldozer, but near Hereford works on a new road project are being held up by a serpent. Or at least that is what it might be.

Nobody knew the Rotherwas Ribbon existed until earlier this year, but archaeologists working ahead of the bulldozers on a new road project have found a new archaeological site. The Ribbon seems to be nothing like existing UK sites and because only part of it is exposed, we don't know what future excavations will reveal. It must be an exciting time for archaeologists waiting to see what else might turn up at this site.


View Larger Map

For those involved in developing infrastructure it is more complex. I am excited by this discovery like archaeologists, but events like this always concern me. It is human nature to personalise events and infrastructure projects are no different; people associate infrastructure projects with the people who design them, build them and those who procure them. If a project is seen in a bad light, the people who build it are also often seen in a bad light. Even worse the people who build it can be seen as evil people intent on destruction.

This is not helped because of the negative image that infrastructure projects often have in countries where there is a good existing infrastructure. In these countries the effect of a project can often be small, with the public finding it difficult to engage with it. There is little passion for the project, but in contrast there might be a lot of passion about some of the perceived negative consequences. People fight to protect things that they feel might be damaged by a project; culture, the environment, tranquility, history. And that fight is often vocal, makes good stories for the media and draws in the public.

The negative perception of engineers is important, but it is not what concerns me when problems like the Rotherwas Ribbon occur is not how the public sees it, but how those involved in the project manage it. Often projects are well managed and come out with a good outcome, but things do go wrong. It is these projects that do go wrong which are the most damaging both for for the perception of the industry, and for the legacy that we leave behind. Good decisions have to made to avoid costing the taxpayer, the environment and our cultural heritage both now and in the future.

I wish those working on the project well. I have no doubt that hard decisions are being made by everyone on the project and that there will be a good outcome. I look forward to the day that I can go an visit the Rotherwas Ribbon in an environment that befits such an important piece of archaeology.

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)

Ancient mysteries and the Litho Lift

I have a deep fascination with the problems faced by ancient people in constructing their monuments. I know I'm not alone in this and it is a lucrative business these days with countless websites, television programmes and books all claiming to have cracked one of the ancient mysteries.

I stumbled upon another solution to the stonehange problem today (Stonehenge building riddle tackled). I love this solution, it is such a compelling machine; one of those solutions that seems obvious only when you've seen it. In some ways I wish I was the first person to have come up with this solution; and yet I know that it can not have been the way Stonehenge was actually built.

I would like to look at the Litho Lift initially from a pure engineering viewpoint. Looking at the scale model of the machine by simply taking moments it is clear that the force in the ropes are greater than the weight of the lintol stone itself. The inventor of the machine does propose a solution to this, by using counterweights to balance the load. To me, this is the start of the process of laying solutions on top of each other. You create a solution to a problem, it seems a nice solution so you decide to run with it. The only problem is that another problem is created. So you add some additional complication to your original solution to solve that second problem. That second solution then creates a third solution and so your original elegant solution ends up being surprisingly complicated.

Often, it is possible to have avoided the complex solution simply by picking different a different solution to begin with. The solution might not be as ingenious as the Litho Lift, but it would have been far easier to implement.

I have tried to put myself in the position of the people trying to build Stonehenge; I have no doubt these people were master craftsmen, with skills and knowedge often far exceeeding our own. I am not so sure that their ability to conceptually generate complex solutions to problems has reached our level of skill. Complexity and the tools used to manage it are features of the modern world , as are the tools and skills we have created to manage it.

I can not see the people building Stonehenge having used the Litho method to lift the lintols. To avoid creating a complex solution from scratch, large parts of the solution must have already been developed before Stonehenge was built. It is difficult to see how any of the individual parts of the machine would have benefited Neolithic man without the other parts. Of course I could be wrong, I am using essentilly the same argument against mans ingiuity that is used against natural selection evoving the eye.

My argument for not using the Litho Lift somehow does not appear to be as strong as my instinctive feeling that the Litho Lift is not the solution that was used. In the end, it is not my rational argument that sways the case. It is simply that I have moved one ton stones by hand as part of a team, and I have built large timber structures. I know how difficult it is creating a large timber structure and how simple it can be to move large loads with levers and brute force. I have no doubt that the people who built Stonehenge would have also gone for the simple solution - all they would have needed was patience and time, something which past generations have always demonstrated.

I am going to take it as my lesson for today. If I am going to try and develop an elegant solution, I must have experience of working with a problem. I must have an understanding of how much effort it actually takes to solve a problem with brute force and patience compared to inginuity and elegance. Sometimes the solution that involves the least work is not the right one.

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

I think it's time for something positive, it's not good to dwell on the negatives too long. One of the greatest gatherings of minds in the world are the TED conferences. An astonishing array of people attend all with there own ideas and stories to tell. Bill Clinton, Al Gore and Bono have all given talks in recent years. 

Standing ovations are not common at this event, so what would it take for a teenager from Africa to get one? Could it be a story of person suffering, fighting against the odds, or making a stand. Not in this case, William Kamkwamba simply had an idea and he had a go. It is something we should all try and do more of. In the words of Nike; 'Just do it'. 

10 years and not much has changed

Last week I realised how little things have changed in the engineering world in the last 10 years. There was a time when the desktop computer was a specialist item. People had to share them, and only used them for special activities. The opposite is true now, an engineer not using a computer is a rarity and even the most mundane activities are now carried out the computer.

This was a massive leap forward, and we are surely still dipping our toe in the water. But what has changed since the desktop computer arrived on my desk? The software is essentially the same. Productivity software has hardly changed over the years. My design spreadsheets have hardly changed over the years, they are essentially the same tools as when I first developed them. The analysis tools that I use are still the same with very few changes having taken place. Even the CAD programmes used by draftsmen appear to have changed little in terms of their fundamental functionality. Changes have been made to these pieces of software, but few of the changes are to the fundamental functionality.

This lack of changes might not be a bad thing: 'if it ain't broke, don't fix it'. And yet I see the same mistakes being made now, as were being made 10 years ago. Errors in the transfer of data between packages, mistakes in the input parameters, incorrect assumptions about the way packages are used and errors in the post-processing of the data are all common. Yet nothing seems to have been done by the software manufacturers to prevent this. Simple tools could have been added with relative ease to reduce the number of these errors.

So why have things not changed? Probably because we don't realise that they do need changing. I suspect that the most contact a software manufacturer has with their clients is when the client is trying to solve a particular problem. If the software can't solve the problem, a quick and dirty solution would be developed in the short term and modifications might be made to a future release so that the software would ultimately be able to solve the problem. This means that each release of software will focus on these specific problems few users actually have, whilst ignoring some of the more fundamental issues that have to be addressed.

We need a paradigm shift in the way our technical and productivity software is produced. Manufacturers need reach out to their users and try and understand how their software is actually used. Equally, the users must start to realise the problems that they actually have. We need to critically assess how we do things and how things can change to make our experience better.

As a last note I thought I'd mention 'Numbers', the new spreadsheet application by Apple (part of iWork 08). This could potentially be a major paradigm shift in the way that spreadsheets are developed. By having multiple tables on one sheet it becomes a much more intuitive interface. It could even lead to modular spreadsheets with a library of tables that can be joined together like a computer programme, each table having already been verified. There would then be no need to check every cell on the spreadsheet, just to check that the tables have been put together correctly. I have yet to try out this application, but I do plan to do so in the near future. I am hopeful that this might be the biggest shift in the way that we use spreadsheets in many years.

It's not often that the world really gets to me, but the world we live in, and the people that design our world are changing... and often it is not for the better. 

To engineer things is a natural human instinct. It is one of the many things that has allowed human culture and society to evolve in the way it has. It is not a realm for the elite, but for everyone. Look at a child's fascination for Lego and building blocks. Building things is a natural instinct we all have, and engineering the things we build is part of that instinct. A building block tower is never built randomly, but blocks are chosen to create the biggest, the most attractive or simply the most interesting structure. All children, whether they know it or not, have a natural instinct and desire for engineering things. 

So what has this to do with the problems of the world? The engineer has always had the skills of a child; the ability to create, to study, to learn by experiment and to design a solution using their natural instincts. These skills we learn as children are probably the most important skills we have as engineers. I've lost track of the number of times that the numbers have said something should work but my instincts have said it wouldn't; and more often than not it was my instincts that were right and the numbers had that had the problem. 

But things are changing, the childlike skills are loosing their value and engineering is becoming all about the numbers. There must be many reasons why this is happening, it is so pervasive and yet damaging to the world that there must be a wide range of pressures that are causing the changes. 

I want this blog to be my fight back against the way that engineers are changing. Numeracy and the ability to enumerate problems are important skills for engineers, but the instinctive skills we learn from our childhood onwards are far more important. I want people who read this blog to be reminded of the skills they learnt as children and how important they are everyday in creating a better world. 

p.s. I choose the name of this blog from the book 'Design for the Real World' by Victor Papanek. In my opinion this should be required reading for all engineers.