Conquering Complexity
10/03/05
There was a time when problems were easy to solve. Want some food? Make a sharp pointed stick or sharp rock to spear a deer or marmot. Need to get around? Once you figure out how to make a wheel, sticking two of them on a flat bed and calling it a cart isn't too tough. Now, thousands of years after those first design challenges, humans are still making new things, finding new opportunities, and solving new problems. As we have grown more complex in our application of technologies to problems, and we find each new challenge more complicated than the last, how can we ensure that our problem solving strategies are up to the challenge?

How are products designed? In his book "the success of open source", author Steven Weber points out that there are two ways humans know of to solve problems: Engineering, and Evolution. Thinking about how each of these strategies pertains to your own particular design problem can be a big help in formulating a solution.
Engineering is a process of refinement toward a set goal. You figure out what you want -- say, a device which makes bread uniformly toasted -- and you head off in that direction. First, you might make a forked stick to skewer the bread over the fire. Then, you might go for a metal contraption. After a while, you might decide that the fire was too uncontrollable, and substitute an electric element in its place. All the time these various revisions are going on, there is a judge of the progress, usually the designer, saying "this isn't good enough, let's try something better". The drawbacks of the engineering approach are that the goal must be at least somewhat defined, and you must have someone who is able to judge the success of each revision.
Evolutionary processes leave out this idea of a designer. Rather than having discreet problems and solutions, a sort of "problem space" is defined, and individual solutions are given the ability to change themselves, or their replicates. Then, the problem space acts as a filter to remove "unsuccessful" solutions. The useful thing about evolving objects is that they require no intelligent intervention; you don't need a boss to oversee their production process. On the other side of that coin, though, it's easy for the "solution" to end up being very unexpected -- good, or bad.
As our modern design problems grow in complexity beyond what any one designer is capable of, we need to explore how permutations of these two problem solving strategies can help us meet new design demands.
One way that this has been done in the past is the classic division of labor. Get each worker on an assembly line to do one discrete part of a whole, and you'll come out with lots of whole objects, fast. The same strategy is employed in designing everything from toys to cars. Marketing comes up with the niche. Designers outline a product to fill it and make drawings. Engineers help manufacture the product and marketing comes in again to sell it. And, within each discipline, divisions multiply; electrical engineers work on circuits, mold engineers work on molds.
Division of labor works, but it is highly dependant on skilful co-ordination of the different workers. There are also problems with lack of excitement from the workers, since they only get to work on a very small part of the whole. Most importantly, it tends to hold back innovation by forcing members to be in the wrong place at the wrong time. Often, great design breakthroughs come from taking a person with expertise in one area and getting them to work on a problem in another. A designer used to working on toys would give an entirely different perspective to a kitchenware design team than someone who has been cranking out toasters their whole career. But overseers looking for a worker to fill the toaster division are more likely to go for a previous toaster experience guy than someone outside that description.
A much more recent and recently en vogue design method is the idea behind open source production. This is a much more evolution-based paradigm. For the development of a program like Linux, millions of contributors from all over the world have added their knowledge and ideas (and brute force coding) to this beast. Due to the nature of the legal language defining the licensing of the code, anyone who uses the source as part of their project must make their project open source as well. This leads to a kind of reverse patent, where instead of building more and more proprietary stuff, you create more and more complex data which is free to be used.
True to the evolutionary strategy, versions of Linux, or other open source projects aren't killed off by some boss when they don't work. Instead, the problem space -- the internet full of users -- will keep working on them, and keep them alive only as long as they continue to show promise in meeting the problem space demands. As the user needs change, so must the program, or it will be dropped for something better. At other times, it may be that two groups with divergent goals for the software will emerge. Programs like Linux and others like the B2 web log engine have split when development groups wanted different functionality. Now, there are multitudes of Linux builds, many with very focused purposes.
The most exciting thing about open source is that anyone with a great idea can add it in any place in the design. Creativity becomes less about being in the right place at the right time, and more about being good at convincing others of the value of your idea.
So, after all that, where is the place for physical designers in all of this? Well, imagine what it would be like to have open source products? It might not really be possible yet, because of differences in ease of replication of computer programs and physical objects, but it probably will be possible within the next 20 years. What will product design be like then? Is it possible for your designs to embrace a little of this open source spirit now? What if you created a car which was sold with full engineering and electronics specs? Or ones that were available online? Maybe users would buy a yearly subscription to the source of a design, like a TV, and be able to send in their physical embodiment of that source every 12 months to have it updated. You might start out with a plasma TV screen with a certain kind of control, then, over time the controls would change to reflect new advances in technology. At some point you would have a new screen, maybe CRT with carbon nanotubes, 3mm thick and roll able. Then, one day you would send it in, and be given the choice to continue on the track of the TV-like device, or a new implanted big screen TV dreamed up by a rogue team at the company.
The idea of the division of labor is solid. But it's probably too slow for out faster and faster paced marketplace with thrives on variation. Division of labor breeds small evolutions, not big revolutions. Maybe it's time for a different kind of design animal.
Previous post: Humansys: Focused VS Peripheral Next post: Bionics: Abandon Perfection
Copyright 2004-2006
Dominic Muren and IDFuel Team

|