The Less is More Revolution

The Less is More Revolution
By David Pallmann, Director, Custom Application Development, Neudesic

I'm making it official and declaring that we are now in the midst of a major revolution in computing, perhaps with overtones that extend beyond technology. I'm calling it The "Less is More" Revolution. It amounts to a major refactoring of how we do things, ...of how we do everything.

When I say "Less is More", you probably think instantly of Apple, one of the great success stories in applying less is more as a design principle to hardware and software. If you're not a proponent of less is more, spending 10 minutes with an iPhone or an iPod will likely make a believer out of you.

But "Less is More" didn't start with Apple, nor does it end there. The phrase has actually been around since the 19th century. One of the founders of modern architecture who used the phrase often and believed deeply in simplicity of style was Mies Van Der Rohe, who dabbled in both architecture and furniture design. So less is more isn't new, but it is coming into full bloom.

"Less is More" certainly makes sense as a UI approach. The 80/20 rule frequently applies: you may find you can provide the important 80% of possible functionality with a mere 20% of the UI that you would need to cover everything. Not that this comes easily or automatically. It's not hard to make a simple interface that does simple things, nor is it particularly hard to make a detailed interface that does many things--but who wants to use either? What takes work and validation and refinement is finding the sweet spot where a simple and pleasing UI yields the most power for the user. That outcome is worth the extra effort it takes to get there.

Social networking web sites such as Facebook also demonstrate less is more. I and just about everyone else I know are on Facebook or similar sites constantly, and the primary activity is to update our "what are you doing right now?" status and view the status of others. From a computer science perspective, this is not exactly rocket science. From a social perspective, it's huge: I actually feel closer to friends and family today, many of whom are thousands of miles away, than ever. I feel more a part of their lives. It's a little thing with big implications. It's less is more.

The Agile Manifesto and accompanying interpretations are a good example of less is more in software development methodology. By focusing on what's important and reducing emphasis on the less important, you measurably accomplish more by doing less. In other words, less is more can be applied to process. This has great implications for improving business process itself as well as the technologies that support business process such as workflow engines.

"Less is More" has been popping up as a principle in web technologies as well. The influence of REST, an approach to simplifying the way data and resources are exposed on the web, is phenomenal. When I worked at Microsoft during the time when WCF was being developed, I don't think I heard the term "REST" once. Today, not only can WCF do REST, support for REST seems to permeate just about everything Microsoft is doing. Don't believe me? Search MSDN for "REST" and you'll get close to 500,000 hits.

"Less is More" and REST are both utterly pervasive in Windows Azure, Microsoft's cloud computing platform. Just about anything you could want to do with the cloud computing platform can be invoked or accessed as an HTTP REST URL. That includes database storage and queries with SQL Services. At the recent PDC convention in LA, Don Box and Chris Anderson showed the attendees just how much they could accomplish using just REST and simple web HTTP requests. You can watch the video here.

In the cloud computing case, the "Less is More" effect is quite pronounced. As Microsoft extends its enterprise platform into the cloud, with new capabilities and new business models, you might well expect increased complexity in designing, implementing, and deploying software. Instead, there's less work involved. Things are just a lot simpler to get at and work with and combine and deploy, thanks to some great design decisions. I do have to admit "less" also rings true in another sense: there is less functionality available to you. Because the platform is so young, there are lots of things you give up. The cloud offerings aren't anywhere close to what the enterprise technologies give you, today, but they do give you the most important things. I'll readily admit SQL Services in the cloud appears to give me only a fraction of the functionality of SQL Server in the Enterprise in its present form. Of course that will change over time. The interesting point is, it doesn't matter. I'm going to happily use it anyway, because the "more" the platform gives me more than makes up for the "less": the way the platform is put together is so radically empowering that it's worth it to put up with functional omissions.

I'm thinking less is more is now a firmly entrenched and warmly embraced concept in the minds and hearts of consumers, meaning there's going to be more and more demand for it in everything from web applications to kitchen appliances. A growing portion of the public knows the difference between overengineering and elegant design now from firsthand experience, and everything I'm observing indicates people will flock to refreshing alternatives in droves at every opportunity--even when there's some additional cost involved.

"Less is more" is sometimes defined as "minimalism", but I'm not sure I like that word as it suggests "doing without" or some sort of monastic asceticism. When less is more is done well, you don't feel like you've given up anything. Rather, you feel highly empowered and effective. When you encounter less is more engineering in your daily life on a regular basis, the sun shines a little bit brighter, the sky is bluer, and the birds are singing more loudly and cheerfully than ever. It's a good thing, and when you enter that zone you don't ever want to leave it.

Is less is more a discipline for designers, or is it a something to be mastered by every developer? I say it needs to be both. We clearly won't get less is more pervasively unless designers lead the way with this as a foremost principle, but less is more extends far beyond design, as we've already illustrated. Developers need to practice less is more every time they create a class, implement a function, or design an interface. Remember, less does not automatically lead to more: that result is never an accident. Rather, it's a by-product of conscious intent. For this reason, all developers need a firm understanding of the principle. Fortunately, excellent groundwork has been laid by Martin Fowler and others in advocating refactoring. Less is more fits in with refactoring quite nicely.

What makes me think I'm right about this? These influences have been going on for some time, but my recent foray into Cloud Computing with Microsoft's Windows Azure platform is what brought it all into sharp focus. Exposure to elegance is contagious and addictive. Try it, you'll like it.