How to Design Software for Human Consumption

Most software developers I've worked with so far tend to specialize in knowing how to design software for the machine consumption. The underlying computing machinery (the CPU, the auxiliary data storage, etc.) is notorious for being very finicky, very demanding. In order to appease the incessant tantrums that the machinery usually throws at us, most software people have learned to focus all their efforts on pleasing the machinery.

That leaves human consumers shortchanged. I would like to advocate here the shift away from trying to please the machinery, and to focus our efforts toward trying to please humans. After all, humans are the most expensive resource in this age of knowledge-based economy.

What do Humans Need from Software?

Basically, what we need from software boils down to two things:

1. An answer to some question
2. Processing some information

I won't go here into the gaming/entertainment side of software. Excluding these two aspects of software, everything else seems to be covered by the above two facets.

How to get an Answer from Software?

When you approach a software product with the desire to obtain an answer from it, you are basically doing one of the following two things:

1. You have good reasons to believe that the answer is 'in there'
2. You are 'fishing for results'

In the first case, you are convinced not only that the answer is in there, but also that you've come to the right place. For example, if I lose my driver's license, I'll go to my local Motor Vehicle Branch and ask for a new one. Not only do I know that all the information necessary for issuing the new one exists in some government office, I also know that I've come to the right place. It wouldn't be of much help if I went to the Revenue and Taxation office, for example.

In the second case, you may not be sure that the answer even exists, let alone that you've come to the right place. But you're fishing for it anyway.

How to get Software to Process some Information?

A software product may not only contain the ability to answer pointed questions, it could also be capable of transforming the information. If we compare a software product with a human servant for a minute, we could say that, just as a human servant can assist someone in obtaining something (such as a glass of water, or an instruction on how to get to the nearest pharmacy), software can do the same type of service. But in addition to that, just as a human servant can modify the existing resource and turn it into something else (like, use wheat flour, yeast, salt and water and bake a loaf of bread), so can a software product modify the existing information and turn it into something else (like, use the supplied information about the customer and the product to create an order to be shipped).

In order to enable software to perform such transformations, we need to make sure that the following three capabilities are present:

1. Create new information
2. Modify existing information
3. Delete existing information

Working in conjunction with the ability to answer questions, software can produce and manipulate information, thus offering the whole gamut of services to its human users.

Take the Rails RIDE

Rails is the best-of-breed technology that offers this kind of simplistic approach to software development today. It is based on the idea that any desired software behavior could be modeled on the principles of irreducibly simple fourfold behavior:

1. Retrieve
2. Insert
3. Delete
4. Edit

Any situation could be modeled as either being appropriate for retrieving information, inserting new information, deleting existing information, or editing existing information.

Once we acclimatize ourselves to viewing software modeling that way, we are capable of expressing our intentions to Rails without worrying about how will these intentions be implemented under the hood.

Such arrangement finally opens the door for us to start worrying about the human side of the experience, and to stop fretting over the machine side of the equation.