Dr. Dobb's Journal December 2006
Let's see. Is it "simple complexity" or "complex simplicity"? I'm never quite sure which is which.
The one thing I am sure of, however, is that technology in general, and computing in particular, is becoming more—not less—complex. But hasn't that always been the case? As Nokia Research head Bob Iannucci recently pointed out when discussing the evolution of telephones, telephony all started with one person and one phone call. No phone numbers. Voice activated. A life-enhancing experience. "Hello." "Goodbye." You can't get much simpler than that. Then simplicity-wise, everything went kaput. And when it comes to computers, what's simpler—an Altair 8800 with its 16 on/off switches, or .NET with its 8000-plus APIs?
Of course, driving the complexity bus are consumers, who usually expect—and occasionally demand—more and more features be stuffed into their stuff, and engineers who love to figure out how to do just that. With stuff like mobile devices, this usually means flashier UIs, louder music, higher resolution cameras, longer battery-life, and lower prices, among other features. But the result is, you guessed it, greater complexity in both hardware designs and software implementations.
Inevitably, the 90/10 rule kicks in. That's when 90 percent of the users use 10 percent of the available features, or 10 percent of the users use 90 percent of them. According to one recent report out of France, for instance, only 15 percent of the people who have MP3 players built into their phones actually use them. Okay, so maybe it's the 85/15 rule. Whatever.
In any event, simplicity and ease-of-use remain at the top of user's "we want it and we want it now" list, whether on the desktop or in someone's pocket. After all, isn't that why we have GUIs instead of command-line prompts, speed dialing instead of crank phones, IDEs like Eclipse and Visual Studio 2005, and frameworks like Ruby On Rails?
But there are reasons to chase simplicity other than end-user ease-of-use, something device manufacturers certainly understand. A device with fewer components costs less, can be manufactured faster, and is likely more reliable than those with more components. The RF engine in Nokia's 3G (WCDMA/EDGE) Slide Phone, for instance, is half the size of most other mobiles around, while its broadband engine is two-thirds the size of other phones. This is part of the reason why Nokia can produce 10 cell phones a second all day long, 24 hours a day, seven days a week. Additionally, compact designs require fewer materials, and therefore less expense. Fewer materials, lower costs, higher profits. Sounds simple enough.
Still, while users might see "simplicity" and "ease of use" as two peas in the same iPod, there's a big difference from an engineering perspective. There's a lot of complex engineering involved in making devices like cell phones simple, small, and inexpensive. It's akin to developers using off-the-shelf components to ease (and speed) software development, forgetting about all the complex engineering that went into building those widgets in the first place. And that doesn't even include the infrastructure (like those 8000 .NET APIs) that the component-based applications run on.
What this comes down to is that when simplicity is the goal, complexity is the unavoidable byproduct. And if you can't stamp out complexity—which you can't, and probably don't want to anyway—what can you do? The answer is simple, in a complex sort of way. You manage complexity, instead of letting it manage you.
How do you do that? Well one way is to design from the ground up with modularity in mind. It doesn't matter if you're building a client/server mission-critical enterprise Web-based application (whew!), a mash-up of your favorite movies, or a next-generation mobile device. Breaking down big problems into little ones makes it possible for you to do things like schedule, design, implement, and review in a efficient manner.
Another key to managing complexity is collaboration. Don't be afraid to talk to your peers about the problems you've encountered. These days, it doesn't matter if your collaborators are in the next cube or in a similar cube on the other side of the world. Read and use open-source code. Go to conferences. Take your buddies (and favorite magazine editors) out to lunch.
While there are certainly other keys to managing complexity, these will get you started—and none are as simple as taking an editor out to lunch.
Jonathan Erickson
Editor-in-Chief
jerickson@ddj.com