What is the purpose of Software?

My friend Grant Rule posted an interesting question on LinkedIn. He asked, “What is the purpose of software?” To me the answer is obvious and the purpose of software is to solve problems. Too many software applications are being built without a clear problem to solve. Too many in the field of software development focus on what the technology can do.

Let me make an analogy for you. I travel a lot internationally and I went to my bank (Bank of America) and asked for a line of credit. The banker said,” of course we can give you a line of credit” and then she asked, “what problem you are trying to solve?” I explained that I travel a lot international and run up large expenses. The problem, in my mind, was the time between when I was paid by a client and I had to pay my credit card bills. The solution, in my mind, was a line of credit. Notice I had the problem and solution well in my mind. Then said asked me if she could offer a potential solution. She suggested, “Why don’t you ask your clients for a percentage upfront to cover your expenses?” It turns out I did not need a line of credit at all. I have taken her advice and it has worked well.

To many “customers” of software applications do not know what problem they are trying to solve and therefore cannot offer a solution. Tom Kelly (The Art of Innovation) points out too customers do not have the ability to articulate what is wrong and especially what is missing. So if the purpose of software is to solve customer problems, and customers cannot articulate what is wrong and what is missing, then exactly who is suppose to articulate the problem and potential solution?

Hide Complexity!

If your mind is empty, it is always ready for anything.  In the beginner’s mind there are many possibilities; in the expert’s there are few. 
- Shunryu Suzuki – roshi (1905 – 1971)

When developing software intended for human interaction (the user interface), there needs to an effort to hide complexity.   In sharing his ideas on complexity, John Maeda writes, “Hide complexity through brute force methods.  A classical example of this technique is the Swiss army knife.  Only the tool you wish to use is exposed.”

When developing software there is a tendency to expose all the complexity and put it right in front of the person interacting with the software. Too often there is a feeling that all the features need to be exposed, so to demonstrate all the hard work that went into developing the product.   Like the Swiss army knife software features need to be exposed only when they are needed.  In other words all the functionality is hidden away until needed.

When all the functionality is in the face of the user, screens become cluttered and it becomes difficult to navigate through all the functionality.  Often a software developer has a sense if they do not expose the functionality the user will never find it and it will never be used.  Instead they need to hide the functionality, expose it at the right moment, and the design needs to be intuitive.

The problem is that intuitive design is very difficult to do and requires the designer to understand how the software application is going to be used.

John Maeda blog (website) http://lawsofsimplicity.com/

Read more at Reboot! Rethinking and Restarting Software Development.

Published in: on September 22, 2009 at 01:01  Leave a Comment  
Tags: ,

Brunelleschi’s Dome

In the late 1200’s it was decided that Florence needed a cathedral that would rival the cathedrals of London and Milan.  The original planners had envisioned a cathedral with a dome that would be the largest dome ever constructed.  They decided to move forward with the construction even though the designers were not certain how the actual dome would be constructed.

Brunelleschi's Dome

Brunelleschi's Dome

For nearly a century it was obvious that no one in Florence or anywhere for that matter had any clear idea how to construct the dome.   All attempts to build the dome had failed and the cathedral was domeless.  While the intent of the dome was going to represent civic pride it instead was a constant reminder of failure and embarrassment.   The story does not end here.

The original planners had been overly ambitious.  All contemporary building knowledge had been exhausted.  The man that would eventually design and oversee the construction of the dome was named Filippo Brunelleschi.    Brunelleschi believed the secret of the dome was not in contemporary knowledge but held in the past.  He would resurrect forgotten concepts by studying the ancient architecture of Rome especially the Pantheon.  He spent over a year studying the Pantheon and it eventually gave up its architectural secrets and he had his solution.   He designed and constructed the largest unsupported dome in Christendom. The dome is an architectural achievement that architects still marvel at today.

Sponsors of software projects can be overly ambitious too.  One of the problems with iterative development such as Agile is it is based upon design as you go. One of the problems with designing as you go is the probability of creating undesirable constraints. Brunelleschi knew he could not tear down what had already been built.   He could not start from scratch.   The outer walls of the cathedral had already been constructed and this dictated the size and shape of the dome.  The same thing happens in software development where previously written code and design constrain all future solutions.

The requirements of the project need to be outlined and the technical solution needs to be understood.  The degree of understanding needs to be in proportion to the importance of the problem.  It was not a good idea to start construction of the cathedral without a clear understanding of how the dome would be constructed.   Lucky for inhabitants of Florence and everyone who has visited the city that Brunelleschi appeared on the scene.

Brunelleschi documented his project in secret code he only understood to maintain controlPlans over the project. He even refused to explain the details of his plan to the project sponsors. They had no choice but to tolerate Brunelleschi’s difficult and uncompromising behavior.   He documented the project without any intention of communicating, so clearly the reason he documented the project was because it was too complicated for him to do all the analysis in his head.

Brunelleschi’s Dome: How a Renaissance Genius Reinvented Architecture (Paperback)

The Laws of Simplicity for Software Design

The whole idea of software development is to create the Right Requirements not just any requirement.

John Maeda outlines ten ways to reduce complexity in his book The Laws of Simplicity.   While he outlines ten ways to reduce the complexity of any system or product,  the most important to software development is to reduce and learn.  The book is a must read for any software developer that wants to create Right Requirements.

Reduce – The simplicity way to simplicity is through thoughtful reduction. One reason software applications are so difficult to use is due to the fact there is too much functionality.  In other words,  the same result could have been achieved with less functionality.

Software developers need to constantly ask the questions, “how simple can it be made?” and “how complex does it have to be?”  It is the difference between “wow” and “whoa.” To often the software developer takes the shock and awe approach to the amount of functionality delivered.  They does this in hopes of “impressing” and overwhelming with confusing complexity.

Learn – Knowledge makes everything simpler. This is related to the law of reduction.  To often a lot of functionality is created since little is known about the actual business problem.  Functionality is created in hopes of accidently creating needed functionality.  This causes software applications to be bloated and confusing.

Published in: on June 9, 2009 at 08:20  Leave a Comment  

Software Does Not Have to Be Ugly

Clean design is harder than it looks
Not long ago I was able to visit the Biedermeier exhibit in Milwaukee Wisconsin, USA and later in Vienna, Austria.  As the curators of the joint exhibit in Milwaukee, Berlin, Paris and Vienna point out  the Biedermeier movement invented simplicity.  In essence it was  a move towards simplicity of design and clean lines.   Biedermeier refers to the work in the fields of music, art, literature and the visual arts that took place between 1815 and 1848. 

Software development needs a Biedermeier movement.  It needs to move from complex design to simplicity.  It is important not to confuse simplicity with simple.   The features and functions that are exposed to a person using a software application need to be clean and concise.  Nothing should be exposed that is not necessary until it is needed.  

Exposing Bad Design
The internet  and the proliferation of websites and especially customer self service websites did not create bad design because it only exposed it.  When software applications were deployed within the bowls of a a large organization few saw it.  The internet has allowed everyone to see an overwhelming lack of design skills. 

Internal Beauty
The inter-workings or the internal design of a software application needs simplicity too.  If what gets exposed is a design mess, then it is probably a safe bet what gets built under the hood, internally,  is a design mess too.  Poor internal design makes it hard to maintain and enhance a software application.  Poor design makes it difficult to understand “what is going on.”

Towards Great Design
“Great design gives no more than its purpose requires; its artistic resources are the very simplest; its arrangement and relationships are the most natural and comprehensible; it is far removed from all ambition, all splendor, and all overburdening.  It is not rich and does not deceive; but it is certain, virtuously true, and intimate.  It proceeds in a strong, straight line to its goal; and a certain childlike sincerity is evident throughout. “   — German Encyclopedia 1844.

Things to Read
When I travel and work with software developers I often glance at their bookshelf’s.  And  I ask myself, “What are they reading?”  When book shelfs are full of books about coding and nothing about design, then it is a safe bet the developers know little about design.  In the end you are what you read.  

The following are two great books about design.

Universal Principles of Design – William Lidwell

The Laws of Simplicity – John Maeda

Published in: on February 20, 2009 at 21:37  Leave a Comment  
Tags: ,