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?

Great Software Design Ideas from 1844

The following quote is very applicable  to software development in 2010 even though it was written nearly two centuries ago.

“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.

http://www.idsa.org/

http://www.bitrebels.com/design/wow-genius-way-to-describe-great-design/

http://joelongstreet.com/

Reboot! Rethinking and Restarting Software Development

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.

Is software an art form?

If software was truly an art form, then the same adjectives used to describe art would be used to describe software.   I often software developers ask, “What three words best describe your software applications.”    Seldom do I hear words like, beautiful, elegant, sophisticated or graceful.   On the other hand,  I have had many  say, “Alt, Control, Delete.”

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

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 control 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.

Are software developers like the janitorial staff?

I think everyone remembers being a kid at the big Thanksgiving or some other family get together.   It is pretty common for the adults to sit at one table and the kids to sit at another table.   I always wanted to sit at the table with the adults, but my grandmother told me I could sit at the adult table only if I acted like one.

The following video was put together by a young film maker named Jordan Kerfeld.

Today the business is at the big table and software development is at the kids table.  When software developers have no desire to learn about the business and especially when your team has no desire to learn about the business, then why would the business ever invite you to be part of the business.

Software development is the only industry we have where workers move from industry to industry. It is time software developers learn and study the core business.

Read More at Reboot! Rethinking and Restarting Software Development.

Got industry experience?

Often I find myself just sitting around thinking.  The other day I started searching several online job posting websites.  I was wondering if other disciplines require  knowledge  of the core business.  In my quest to figure this out I reviewed over 500 job postings for a variety of different technical disciplines including mechanical engineer, electrical engineer, chemist, and biologist.  In each case, over 90 percent of the job postings required industry domain expertise.   For example, a job posting for a mechanical engineer required 11-14 years of experience in production packaging of electronic equipment.   The same was true for chemist and nearly all chemist jobs required domain experience or knowledge of the core business.

Let me stop and review.   If you are a chemist then your future employer wants you to know about chemistry and the industry (core business).  The same is true if you are a mechanical engineer or electrical engineer.

This is in sharp contrast to software development.  When I examined job posting after job posting, almost none required any knowledge about the core business.   Out of 100 job postings for software developers that I  reviewed only 4 required industry domain knowledge.   Think about this for a second.   Poor  requirements plague the software industry.  Do ya think it has anything to do with the fact most software developers have no knowledge of the core business?  Come on folks!

One could argue that it is better to be a generalist instead of a specialist, but no other industry suffers as many project failures has software development.  No other industry frustrates end users like the software industry.  No other industry has such a problem with requirements as the software industry.

Read more at Reboot! Rethinking and Restarting Software Development

A software application should have no unnecessary functions!

Many years ago I learned a very important idea and this idea has stuck with me and benefited me.  The idea is E.B. White’s seventeenth rule in The Elements of Style:

Omit needless words.
Vigorous writing is concise.  A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.

A software application should have no unnecessary functions. Just like writing can be bloated a software application can be bloated too.   The reason software applications have unnecessary functionality is due to the fact the person designing the application did not have a clear understanding of what the person using the software application wanted to do.  Too often it seems like requirements just rain down on the software development team.

The question, “What do you want the software application to do? “ is an incomplete question.   To design a software application well requires the software designer to study how the user does his or her activities.  A software application needs to be designed so it fits naturally into the flow of work or activity.

If the software designer has not studied how a person works and designs the software around the natural work flow, then there is a high probability the software application will be bloated and a lot of unnecessary functionality created.   It would be nice if the rule was expanded and would read as follows.

Omit needless functions
Vigorous writing is concise.  A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines, a machine no unnecessary parts and a software application no unnecessary functions.

For more read the free online book www.RebootRethink.Com

What’s your major?

The most common opening line at a bar near a college campus is, “So.. what’s your major?”  To be honest the answer does not really matter because the question is designed to start a conversation.    The same is true when I ask, “Where does software development belong?” because the point of the question is to stimulate some conversation.   Does software development or computer science warrant its own department or division like physics, economics or accounting?

You are probably thinking stop asking questions and give me some answers.  It is not clear at all where the discipline software development or computer science belongs.   There are some that argue software development is branch engineering and degrees related to software development need to be conferred by the department of engineering.  Others maintain it is a management science and should be part of the college of business.  Still others think that software development is a natural branch of industrial design.   One thing has become clear there is no consistent coursework for those getting degrees in software development or computer science.  Software development is an industry that struggles defining terms like software life-cycle or software methodology.  It is common that new software methodologies pop up like Agile or RAD (rapid application development).  These methodologies go as fast as they came.

I believe software development belongs in Industrial Design.  The professional organization Industrial Design Society of America (IDSA) defines industrial design (ID) “is the professional service of creating and developing concepts and specifications that optimize the function, value and appearance of products and systems for the mutual benefit of both user and manufacturer.” If we change the last sentence to read … for the mutual benefit of both user and developer, then we have a good definition for software development.  Where the field of industrial design differs from software development is ID places an emphasis on those factors that relate most directly to human characteristics, needs and interests.  The field of ID teaches how to study customers using techniques like ethnology.

A bit of history
In the early 1960’s universities decided they needed a new department called Computer Science (CS).  These new CS department would be equivalent to the existing departments like Physics, Mathematics, Engineering, Economics and Business.    Graduate schools appeared first and nearly all those getting PhD’s were mathematicians.

One of the first texts used in computer science courses was An Introduction to Digital Computing published in 1963.  The book describes the method to write code to solve complex mathematical problems like least square analysis, Taylor series and differential analysis.   The new programmers, most of them mathematicians, used computers to solve really hard math problems.  Before the arrival of computers a small army of graduate students would have to make tedious calculations using a slide rule.  Most of the early computer programs were used to solve complex math problems and the user and programmer were the same person.

Today about half the degrees related to “software development” are earned in the department of engineering and the other half are granted from either arts & sciences department or the school of business.   The course work required for these degrees varies from one department to the next and from one university to the next.   There  is no consistent required course work for a career in software development and this is in sharp contrast to just about any other career.

Where software development really differs from the field of ID,  ID includes a concern for marketing opportunities, sales, servicing products, and economics.  Software developers have basically no education or training on anything relating to marketing, sales, economics, and especially design.   Unfortunately software developers have little desire to learn about marketing or sales either.  To many software developers believe their role is to just write code or just to program.

Study The Customer
The field of Industrial Design includes a significant amount of study of the actual customer and his or her business.   Today most software developers move from industry to industry and have no specialized industry knowledge.  This would be Okay if they understood how to study an industry, a business or a customer, but they don’t.

One of the largest problems facing software development today is gathering or eliciting requirements.   The reason  developers are not skilled at studying the customer environment is because they have not been trained to do so.  In the end most people do not know what they want, so it is wrong to expect a user to provide requirements.

I would recommend that all software developers join the Industrial Designers Society of America (IDSA) – http://www.idsa.org and learn some new tricks from another discipline.

Read more at the free online book Reboot!  Rethinking and Restarting Software Development.  (www.RebootRethink.Com)