I've always thought if you make something simple enough that everyone can use it, then everyone will. This is becoming more and more apparent as we try to find innovative ways to make our lives easier with technology. In my line of work, I have responsibilities that range from application architecture design to detailed specification design to actual application development. I try to look at everything I do from a point of simplicity. To provide a robust and adequate design, some people think you have to build a complex diagram of integrated systems and multiple layers of sophisticated interlocking components or it just doesn't make sense. Application and system architects today have a broad base of knowledge from Internet and intranet infrastructure designs to multi-layered redundant hardware and software backends. Of course, there are places where it makes sense to apply these technologies; banking and Internet commerce are great examples. But when it comes to how users are going to actually apply and interact with this technology, I find that simplicity is often absent from the overall picture.
When designing any product from the ground up, be it a Web application or a paper plate, the most important thing to consider is who will be using it. It’s difficult to be successful if you do not actually think about how the users of a product will actually use it, and instead focus on complex architecture diagrams, buzz words, and other high impact elements that might impress a management team. It's very easy to get lost in the forest of pre-existing architectural designs and the mountains of specifications that are, ironically, designed to make your life easier. In my opinion, most of these specifications and designs try to take every possible solution into consideration – which is fine, except that this tends to make them very bulky, slow, sometimes incomprehensible, and ultimately difficult to implement in the real world. If you want a product that works and that everyone will use, you better make it simple.
Let me give you an example of what I mean.
Think of something that you use every day, but might take for granted: your e-mail. How simple is e-mail? I mean, you type up your thoughts on your e-mail application of choice, whether it be Gmail, Yahoo Mail, Hotmail, IBM® Lotus® Notes, or something else, and send it to a friend or colleague. They read it and then maybe respond, delete it, or forward the message to someone else. All e-mail clients do basically the same thing: they take your written word and send it to a server which then sends it to someone else to read. Ray Tomlinson, the inventor of e-mail, provided one of the simplest architectural designs in the world, to which little has changed since 1971. Even the @ symbol is still used today. What it comes down to is this: if you want to create something that everyone will use, then make it simple enough for everyone to use.
I see many applications today that try so hard to provide everything in a single basket that even the original architects end up getting lost in the flow. I was on a project once in a shop where scope creep was considered common practice. Our application started off small and very useful (and simple). There were two architect/developers on this high visibility project, plus myself and another colleague. When we completed it, it did exactly what it was supposed to do and nothing more. Because of its simple design and ease of use, it quickly became popular. Anyone could access the system and use it the first time with almost no questions. Of course, as the application’s popularity grew, so did the visibility and the money. Everybody wanted a piece of the pie. The team quickly grew to 18 people and new requirements from stakeholders started going through roof. Despite the warnings, the project became so complex -- it had about one hundred new functions, four times the data, and more redundant servers than you could count -- that people actually stopped using the application. What went wrong?
Sure, it had all of the new data and functionality the stakeholders asked for, but the problem was that "everyone" – the people who used the application -- didn't need, want, or ask for all that stuff. We were eventually asked to write a help section for the application because users could no longer find what they used to be able to find easily. Something simple and practical had, over time, become very complex and unpractical. This was a mistake that certainly could have been avoided or minimized if the application was either kept simple in the first place or divided into smaller more directed applications for each group of requirements.
Imagine what e-mail would be like today if it hadn’t been kept in check? Certainly, everyone can think of some way to improve e-mail, and indeed e-mail improvements have been made to help it evolve over time. Still, the basic vision of what e-mail was supposed to be has remained the same, which is what continues to makes it so popular and useful.
There are obvious benefits to following the practice of simplistic design, but too often they are not considered until it's too late. Here are the top three to keep in mind when making application design decisions.
Simple is easier to fix
The fewer parts there are to break, the less time it will take to troubleshoot any problems that arise. Of course, part of the reason I have a job is because people can't fix what they have built. Designs sometimes become so complex that no one can understand why something continues to work at all. I often end up breaking components down into smaller, more manageable components to resolve problems. Most of the time, I advise what could be removed from an application as overhead in the process flow. If you must design a complex application, try to keep each component separate from the others. This will definitely help in the long run and make it easier -- for you and others -- to resolve problems when they occur.
Simple is usually faster
Applications follow information flows just like humans. They take steps to get from one place to another. The more steps there are, the longer it takes. Sure, you can just put your application on faster hardware, but why spend more money and time if simply reducing the number of steps will have a similar effect? When I design an application, I try to get from A to B as quickly as possible. It is common today to see applications designed to flow through a common bus or process. Granted, there are cases when this is required, but don't push all data through a bus just because you believe it’s the latest and greatest architectural design. Consider whether it’s possible, logical, and practical to save time and resources to go directly to another process instead. If you own a car, why wait in line to ride on the bus when you can just drive yourself to your destination?
Simple uses fewer resources
If your data models are small, they will take up less space in memory than if they were larger. If there aren't as many steps in the process, you save CPU cycles and potentially battery power on devices. If redundant systems aren't needed because certain data isn't critical, don't implement them. If you know that only one or two options could ultimately be used, why accommodate every remote possibility within the architecture? By providing "just enough" functionality for the one or two requirements that you know are needed, you can save CPU and memory resources that could be better used by other parts of the application or even another project. A side benefit of this practice can be a much less expensive solution as well.
Several recent products and applications have taken simplicity to heart, and it’s no coincidence that they have become extremely popular. What they share is simplicity of design, and there are lessons to be learned from the way each has applied this concept:
So, at the end of last year I decided to see what all the fuss was about. I actually switched from my RIM Blackberry to an Apple iPhone. I needed to develop Web applications for both and was already familiar with the Blackberry. Receiving the iPhone was an interesting experience. There was practically no manual to read, one button on the front of the phone and only a few preloaded applications, like Contacts, Settings, Photos, Mail, Maps, and a couple of other simple ones. I began to think I may have made a mistake. I loved my Blackberry because it was a technical guru's dream and could do, well, just about everything! Sure, I had to dig around to find things in the multiple layers of menus, but that's what made it cool!
Well, I was very mistaken about the potential of the iPhone. After only a couple of minutes with the device, I realized a few things. First, I did not need a manual to use it at all. The simple, intuitive design using just pictures and my fingers was all I ever needed. Second, the iPhone did exactly what I needed a phone to do: make and receive calls, retrieve e-mail and SMS messages, and browse the Internet. It was as simple as it gets. Even the settings screen was just a couple of pages of on/off buttons and horizontal scroll bars. Apple had taken the concept of simplicity to a whole new level. When version 3.0 of the operating system came out, even the updates were minimal and only added essential functionality missing from the first release. The device is actually capable of much more -- but why complicate something that works so well for so many. This is a prime example of the point I am trying to make here.
Here is another great example of something that is so simple anyone can use it. The first element of simplicity found in Twitter is the amount of information you are able to enter as data, which is limited to 140 alphanumeric characters. Most data designers would cringe at this minute amount of information -- e-mail doesn't even have such a limitation, for goodness sake! Even a standard old school string value has at least 255 characters. Of course, this limitation enables interoperability between Twitter and the Short Message Service (SMS) standard of 160 Latin alphanumeric characters and 70 for double byte (another simple and popular design used on cell phones), but this limitation is what makes it so easy to use.
The designers got this one right. There are a list of people you get updates from and a list of people that can get updates from you, and, of course, you can also make your updates public. And that's pretty much all there is to it. Anyone can use Twitter. It's simple -- which also makes it fast -- yet it is very powerful when used in the right context. Because of it's small footprint, you can get Twitter on just about any cell phone. Twitter is another example of a very simplistic application that does exactly what it was designed to do -- no more, no less – and is all the better for it.
IBM WebSphere sMash
One of the unique things about WebSphere® sMash as a Web development platform is it's simplicity. If you need to get a powerful Web application out quickly and want a simple way to do it, WebSphere sMash is the way to go. Because of it's small footprint and easy deployment methods, it is one of the fastest and easiest ways to get a Web application up and running -- literally in minutes.
First of all, there is no real "installation" of the application. If you have Java™ installed, you can just unzip WebSphere sMash into any directory you want. Each application you develop for WebSphere sMash exists on its own so there is no interference with other applications or configurations, which helps simplify troubleshooting. Want a new app called "MyNewApp"? Just type
zero create MyNewApp. Start it by going into the MyNewApp directory and type
zero start. It would be difficult to get much easier than that. The few config files are all plain text, so you can make changes if needed. Popular languages (Java, PHP, and Groovy) are supported, which already contain the basics you need to provide REST functionality right out of the box.
With over a million downloads to date, the popularity of WebSphere sMash is picking up speed fast and for good reason. I have turned to WebSphere sMash for many of my new Web application development, not just for the time it saves to get products out the door, but for its ease of use and extendibility to whatever I need to develop for the Web. I can keep it as simple as I need it to be and add components to suit my exact scenario in more complex situations. As more and more people get involved in the WebSphere sMash community, I'm hoping it heeds the examples set by Twitter and iPhone and remains appropriately simple for one and all.
So far, so very good.
I know a lot of architects are going to say, "I hear what you’re saying, Doug, but there is really no way MY design can be simplified. There is way too much it needs to do." I challenge you to take another look at any design you have to see where you can slim it down or make it less complex. Most larger designs can at least be divided into several, smaller solutions. Especially today with SOA and REST services, there is really no longer a need to have all of your eggs in one basket. By just separating your application into multiple self-standing components, you will already have made the first big step. You might be surprised to find that there are many ways that you can make your designs easier to use, easier to troubleshoot, run much faster, and quite possibly even save some money -- which is simply the bottom line.
Get products and technologies
Doug Phillips is an Advisory Software Engineer for IBM's elite group of skilled professionals known as IBM's Web Enablement and Support team. He has worked in many organizations within IBM and currently designs and develops both internal and external Web applications using IBM middleware and Linux. Doug is WebSphere, Lotus, Rational, and DB2 certified.