How Can ROA Help Us Build Smart Servants?

Pat Maddox and Abhijit Nadgouda are two clever dudes. They tend to ask tough questions, which is fine by me -- keeps me on my toes. I see people like them being at the forefront of the next wave of software development. People who don't take things at a face value, who keep probing and exploring and are not satisfied until everything becomes crystal clear.

Those who do not see any value in such behavior will be left behind, partying on their Titanic while it gradually and almost imperceptibly continues to sink. Eventually, it will run out of escape boats and life jackets.

All right, onto addressing Pat's questions:

How does this thinking allow us, as developers, to build smart servants?

Bingo! Right smack in the middle, he asks the absolute perfect question. But just to flip it around a bit, I'd like to ask a slightly modified question:

Why Haven't We Been Building Smart Servants?

In other words, what was it that was stopping us from trying to build smart servants? I mean, after more than 40 years of developing all kinds of software, why is it that only now are we starting to talk about smart servants?

The reason for it is quite simple: if you're drowning, and are gasping for air, you don't have enough free time and energy to start reciting poetry. And we've been drowning for the past 40 years or so in the turbulent waters of oppressive computing infrastructure woes.
If 98% of our time must be dedicated to serving the finicky infrastructure, there is really no free time left to think about finer things in life. Such as -- a smart servant.

Computing Infrastructure is Rapidly Losing its Luster

We have reached a point where there aren't any more compelling reasons to be fascinated by the computing infrastructure. Naturally, in previous times, when a single computer used to command a million dollars price tag, there was lots to be fascinated with. But today this infrastructure is dirt cheap, and therefore ceases to be the subject of heated conversations. Similar thing happened to the light bulb, the radio, the TV, etc.

We are therefore standing at the threshold of the realization that we are not to serve this dirt cheap computing infrastructure. We are slowly coming to our senses and are beginning to insist that the computing infrastructure must serve us.

What that means is that we're turning the tables on the computing infrastructure. From now on, instead of spending 98% of our time servicing this infrastructure, we don't want to spend more than 2% of the time doing it. It is a drastic, radical turning point, where we basically turn things upside down.

So if you're planning to continue being engaged in using computing infrastructure the way tool vendors are shoving it down our throats (like Microsoft, IBM, Sun, Oracle, etc.), you know with frightening degree of certainty that 98% of your efforts will continue to be wasted on servicing that infrastructure. That means that 98% of your decisions will add 0% value to your business (and will keep adding 100% value to the vendors' business).

If, however, you make a healthy transition and stop eating junk food and embrace the world of resource-oriented programming, you will be forsaking your love affair with the computing infrastructure and will begin embracing the smart server model.

The Honeymoon is Over

Often times, even though the honeymoon is long gone, people still don't feel ready to acknowledge that fact. This is what's happening with the infrastructure-centric software development. Lots of people have fallen into a bad habit, created by the pushers (i.e. the tool vendors), and are now convinced that they must keep feeding the beast. But in actuality they really don't have to keep feeding the beast. Walking away from your dealer is easier than you might think.

It is hard to consider a divorce if you're convinced that the honeymoon is still in full swing. But the time for filing a divorce has come.

Building Smart Servants Takes Full Attention

It would not be possible to build a smart servant if we cannot have our undivided attention focused on it. So long as we keep using the tool vendors' vision of the computing infrastructure-centric model, we won't have the ability to focus on building the smart servant. There will always be something else that is more pressing, more important than the smart servant project.

But if we switch to the liberating technologies such as resource-oriented programming and embrace principles of radical simplicity, the computing infrastructure concerns will cease popping into our head while we're developing software. That experience is very liberating (as all people who've made an effort to learn Ruby can attest for).

Browsing the Resources

Pat then continues his inquiry:

Right now with a resource-oriented paradigm, the only way to use the resources is through a browser.

You don't have to use the resources via a browser. If you can identify and locate a resource, you can send it an HTTP request in more than one way. Then, you'll receive an HTTP response from that resource, and it's up to you how would you like to handle that response.

This is because, as I said, you still need to know the attributes of a resource in order to do anything with it programatically.

You can do a lot of things programatically to a resource even if you don't know any of its attributes. You can ask it to represent itself to you. You can ask it to destroy itself. You can ask it to make a transition to a different state.

So we can publish useful resources, because humans are smart enough to process them, but how can we consume the resources?

As I've already said, we can consume them by asking them to represent themselves etc.

Even if it’s through a browser, you’ve already proclaimed that the browser is a broken model.

True, but we're not forced to stay with the browser. AJAX is leading the way out of the browsing paradigm.

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.