Showing posts with label Complexity. Show all posts
Showing posts with label Complexity. Show all posts

Sunday, September 02, 2007

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.

Tuesday, August 28, 2007

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.