Thursday, January 11, 2007
Keeping it simple...
Posted on Thursday, January 11, 2007 10:21:25 PM (Mountain Standard Time, UTC-07:00)  Comments [2] | 
Categories: Software

One challenge to software developers is to keep software simple. As developers, we are both comfortable with complexity (just look at the Visual Studio interface) and have a tendency to create applications that are complex. The thing is that the end users really just want to get their jobs done. They want software that they don't have to think about. Software that is obvious and easy to use. They want one click not 5, and short-cut keys are even better. Simple is better.

When a user is given software that helps them get their job done, they will use it. If it's also simple and easy to use, they will be happy. And a happy customer is the simplest way to get more customers.

So - beyond the happy user, why should we want to build simple software? The world is complex and does not always follow simple cut and dry rules. Shouldn't our software handle all the possible corner cases? If the complexity is a necessary part of the business process, it will need to be addressed in the software. But we want to avoid unnecessary functions that are not business critical i.e. an RSS reader a parcel management system.

In the end, the level of simplification you can achieve in your application does come down to negotiation with your client, but there are some compelling reasons to avoid complexity. First, as noted above, simple software is easier to use and more likely to be used. This is a big win right out of the gate, especially if it is a new technology deployment. If it's really easy to use, the organization may also see significant productivity gains - which is a huge win.

Additionally, designing simple software forces the team to focus their effort on only the most critical elements of the system and on executing them in the most effective and efficient manner. Keeping the software simple makes it easier to write and easier to test. Corner cases and "extra" rarely used functions tend to eat up a lot of time, add a lot of complexity, and make maintenance and testing more difficult. Since maintenance of software can be 60% of it's total lifetime cost, keeping it simple can save a lot in the long run. Finally - if it turns our that some areas of the application must address more complex aspects of the business process, simple software is easy to extend.

Additional reading on "Keeping it simple"

Conversation with Ward Cunningham  creator of "wiki" - quote: "Simplicity is the shortest path to a solution"

Agile and Extreme Programming, which is focuses on skipping "big design up front" and writing the simplest thing that can possibly work, and adding in complexity only when it is absolutely necessary.

37Signals.com - a web company focused on simple solutions. They build "elegant thoughtful products that do exactly what you want, and nothing you don't". They have written a free e-book about their development philosophy called "Getting Real"

Joel Spolsky (JoelOnSoftware.com) also has some thoughts on "Simple"

Steve McConnell - author of Code Complete in addition to a number of other great books on software development wrote this article on simplicity as a best practice back in 1996

Friday, January 12, 2007 6:13:58 AM (Mountain Standard Time, UTC-07:00)
Dave:

This message can't be repeated enough for the GIS crowd who always seem to want to cram as much functionality into a public-facing app as they have on their own desktop.

And if the GYM interfaces have taught us anything, is that usability is the key--the business landscape is littered with projects that succeeded on their own terms but failed because the target audience decided it wasn't a significant improvement on the way they already do things.

From the business end, the simple/lightweight development philosophy helps keep momentum moving because deliverables (however basic) are being put into the hands of end users quickly. Inertia and techno-skepticism run pretty deep in many quarters.

We're building our own thematic mapping Flash interface these days and the driving philosophy is that the target audience will spend on average 30-45 seconds with the app: enough to pick up the general pattern, click on a couple of features to get detailed info, and then they're out of there. For those of us who've in the past have spent days (weeks?) slaving over map layouts for our 36" x 48" masterpieces, this more impermanent, rapidly changing medium requires us to be more mindful of our target audience (even though there's that dark, curmudgeonly corner of our mind that equates simplification with dumbing down).


Brian
Brian Timoney
Friday, January 12, 2007 8:33:41 AM (Mountain Standard Time, UTC-07:00)
We've spent months *removing* buttons from our mobile product line, for exactly the reasons you have described. Keeping interfaces simple is one of the most important parts of software development, and one of the most difficult.

I didn't have time to write a short letter, so I wrote a long one instead.
--Mark Twain
Rich Ruh
Comments are closed.