Posts Tagged‘engineering’

Form, Function and Methodology.

Conjure up in your mind a picture of the humble nail cutter (or if you have one handy grab it!). Not only is this device a marvel of modern technology it also proves to be a useful example of what good engineering practices should be. Can you figure them out? The same question was posited to one of my classes when I was still in university, and none of us could come up with a good enough reason to satisfy our lecturer. If you take a step back and look at a nail cutter you notice something, there’s not a lot to them.

The majority of nail cutters are made out of a grand total of about 6 parts (Lever, top cutter, bottom cutter, file, front pin and rear rivet). Whilst the whole thing might appear simple on the surface it is indeed a feat of complex engineering. Each of the pieces serves up more than one function in order to achieve the end result. Our lecturer at the time had us try to imagine a nail cutter that’s design only let each piece perform a single function. The resulting contraption was a monstrosity of dozens of parts and if created would have been more than double the size of a convention nail cutter. This exercise was done to teach us the importance of modularity, and when its gone too far.

One of the very first methods you’re taught as an engineer for problem solving is to take what looks like a large problem and divide it into smaller and smaller sections until it becomes managable. We were first taught this in reverse with our first assignments usually serving as a basis for the rest of the semester. However early in our second year we were given what appeared to be almost impossible projects only to have small clues as to their solution taught to us in the weeks ahead. The problem is however, that when you take the modular design methodology too far you end up with innumerable small components which then changes your problem into one of integration. The nail clipper example showed us that you shouldn’t modularize a problem beyond what will allow you to solve it, for want of introducing complexity rather than removing it.

You can see this methodology applied almost everywhere, for better and for worse. It’s one of those problem solving skills that doesn’t get taught in school and really its one skill that I can’t imagine myself being without. If you take the time to analyze any problem you might have and break it down into its basic components nearly anything just becomes a matter of time, rather than brainpower.

Now, go forth and modularize my minions! 😀

The Everyman’s Perception, The Engineer’s Problem.

One of my university lecturer’s had a reputation for talking for hours on end about his previous projects (Dr John Rayner if you’re interested). This wasn’t atypical of many of our lecturers since the majority of them had spent many decades in industry or research before becoming lecturer’s, but Dr Rayner was a curious exception to those who were just being a little nostalgic. He was a physicist turned engineer, which is strange because even though we share some common ground most of us would never think of “crossing the border” as it were. As such we routinely had him sub in when either of our physics or engineering teachers were absent and it was guaranteed that his class would somehow revolve around one of his previous projects. The twist was, even though we’d always think we were just wasting our time listening to him by the end we all understood the material we needed to be taught, even though he rarely delved into the theory required. One of the most interesting lessons we got from him was on the expectations of customers and how that will influence your designs.

He was working on a community housing project in one of the northern states and one of the concerns was water usage. They’d optimized basically everything apart from the toilets so it was left to him and his team to optimize the amount of water that they used. They had then designed a system that used around a tenth of the water of a conventional toilet, a considerable saving. However after passing initial testing (using an IEEE approved analogue for human waste, basically sausage skin filled with sawdust) they then sent them along for their real world exposure. Curiously whilst no one reported any problems actually using the toilet they weren’t well received. As it turns out the perception of so little water being used made most people feel uneasy about the toilets, thinking they hadn’t properly flushed or that they weren’t clean. Thus the design was reworked, although he was coy on the actual results.

This whole lesson came steaming back when I saw this article yesterday:

Researchers have demonstrated a prototype device that can rid hands, feet, or even underarms of bacteria, including the hospital superbug MRSA.

The device works by creating something called a plasma, which produces a cocktail of chemicals in air that kill bacteria but are harmless to skin.

The team says that an exposure to the plasma of only about 12 seconds reduces the incidence of bacteria, viruses, and fungi on hands by a factor of a million – a number that stands in sharp contrast to the several minutes hospital staff can take to wash using traditional soap and water.

The first thing that sprung to many people’s minds is how this could be used to eliminate the need for washing your hands. It’s an interesting idea since the use of this technology could be quite a bit more hygienic whilst saving water and towel waste. However whilst novel and indeed an elegant alternative it will take many years for such things to replace the norm, just because people won’t feel comfortable walking out of the toilet without washing their hands.

It’s a challenge that every engineer will face when they’re designing and building a new system. There are a lot of social and technical norms out there and going against them won’t do anything to help the adoption of your product. I think this is the problem that Google Wave has faced recently since it has melded so many different technologies (and therefore expectations of how it will function) that we’re no quite sure how to go about using it. The fact that it has no real physical analogue doesn’t help the matter either, and that’s why my Wave account sits unused for the better part of a month.

So it becomes the engineer’s challenge to understand the everyman and work with him, since they will become the ones using our creations. I used to look upon this as unnecessary rework but over time I grew to appreciate the familiarity that came with certain lines of products (thank you Microsoft ;)) making learning and utilizing them to their fullest so much easier. A good understanding of your users can be as valuable as a good understanding of the solution, and I’m forever thankful for the eccentric Dr Raynor for teaching me that.