Friday, December 21, 2007

Resource Representation and Discoverability

We now seem to be entering the phase where we are in the process of reclaiming the web. Who are we reclaiming it from? Why, from no one else but the hordes of software developers.

The web has been hijacked by software developers. It is only natural that the people who dedicate their lives to becoming as intimate with the machines as is humanly possible get to be the people who take center stage in building the web. But, there is trouble in paradise. The web is, in its essence, the exact opposite of the machines. The web is all about humans.

Now, software developers are humans, however they are humans who value serving machines more than they value serving other human beings. Because of that, the web is a horrific place right now, fully dedicated to serving the machines.

This terrifying state of affairs must change. And the only way it will change is if humans reclaim the web, pry it out of the slaves-to-the-machine greedy hands, and install it at its proper place -- as a platform for serving the needs of the human mind and the needs of the human social dimension.

Resources and representation

As has been argued elsewhere, resources on the web are mere abstractions. They are not the tangibles that one could indulge in. At best, one can hope to consume the representation of the abstract resources scattered around the web.

It is often erroneously assumed that resources are directly exposed on the web, in their raw form. One example would be the unanimous conviction that URLs are web's native resources. Thus, a URL such as craigslist.org is viewed as a web resource.

Nothing could be further from the truth. A URL (such as craigslist.org) is not a web resource, it is merely a representation of a web resource. There seems to be an abstraction labeled as craigslist.org and hosted somewhere on the web. But what that abstraction (i.e. craigslist.org) really is, we have no way of knowing.

What we can learn about is one or more representations of that resource. For example, one representation of the craigslist.org resource is its URL. Another one could be the list of all the sites offered by craigslist.org. And so on.

What's the use of representation?

Some people fail to see the usefulness of the representation. They'd much rather get their hands on the resource itself, instead of beating around the bush of resource representation. The best way to explain this problem is to employ assistance of some heavy duty science:

Map is not the territory

This famous premise was issued by Alfred Korzybski, one of the seminal thinkers who helped shape the communication and information theory.

A map is the representation of the territory. Without the map, we'd be lost when traveling through the territory.

In a similar fashion, resource representation could be viewed as a map that eases our voyage through the territory (i.e. the resource we're exploring).

Very few people tend to question the usefulness of maps. It is our hope that, similarly, people will learn to embrace the usefulness of the resource representation.

Discoverability

The web is intended for human consumption. Humans are notorious for having fairly constrained short-term memory buffer, and are thus forced to consume information in a piecemeal fashion. The architecture of the web is therefore tailor-built to serve exactly that constraint -- consume the resource representation at a fairly leisurely pace. Expecting humans to consume the resource representation in a single giant gulp would be utterly unrealistic, and so the fundamental architecture of the web is based on the principle of discoverability.

What that means is that, on the web, we are serving byte-sized chunks of resource representations. These byte-sized chunks are intended to be consumed by human users pretty much at a glance. Any need for consuming more, for learning more, gets fulfilled by letting the users explore further, allowing them to discover more intricate details of the resource representation.

Away from the sociopath web

Today's web is mostly built by humans who crave serving the machines. As such, the way resource representations are typically architected on the web today belies the optimization to the way machines consume information. There is typically very little discoverability offered on most web sites, and the consumers of the representation are usually expected to digest insanely vast quantities of intricate information in a single gulp.

It is painfully obvious to even a very casual observer that the web today is not tailored for easy consumption by humans. It is as if some sociopaths, who lack any degree of empathy with fellow human beings, have built most of the web sites in operation today. Come to think of it, sociopaths is the fair characteristic of individuals who value interactions with the machines more than they value interacting with other human beings.

It is high time we start working on getting out of this sociopath hell.

Thursday, August 16, 2007

Why is ROA Hard to Understand?

Resource Oriented Architecture is the term I've coined a year ago, only to discover almost immediately afterwards that others have been thinking independently along the same lines. During the past 12 months, I've witnessed numerous discussion threads and debates centered around the importance of ROA. Most of these discussion threads belie complete misunderstanding of the Resource Oriented Architecture, which is very alarming, given that ROA is the native architecture of the web.

And web is the native infrastructure for information dissemination, exchange, and sharing.

Old habits die hard

Most software developers in circulation today have cut their teeth by learning how to implement computing algorithms. Something akin to: "here is a jumbled sequence of numbers, write a computer program that will sort them in ascending order".

The emphasis in such an exercise is always on exhibiting reasonable amount of direct control over the execution logic. The would-be programmers have been groomed for generations to master the skills of gaining full control over the stream of instructions that the CPU executes. In other words, to be a computer programmer/software developer implies to them that a full control over all the processing aspects must be in place.

It's a single point of human control, same as it's a single point of machine control (i.e. the Central Processing Unit, or CPU).

But in the world of the web, such notions of centralized control are not only ridiculous, they are down right harmful. Still, armies of CPU-trained programmers have now been employed and deployed to develop software that will run on the web.

Is it a small wonder then that such 'central point of control' minded individuals are creating fully dysfunctional web sites? Indeed, old habits do die hard.

New habits are slow to emerge

What the above described situation then means is that the existing workforce that is dedicated to developing software programs is pretty much a write-off. Because old habits die hard, it is quite likely that it will be much harder to unlearn the old habits and relearn the new ones, than to start from a clean slate.

However, given the vast demand for web-based software that is out there, we must work on creating some sort of a compromise, in the attempt to bring the crusty old 'central point of control' software development workforce into the web fold. For that reason, we need to continue explaining the difference between the Central Processing Unit software architecture, and the Resource Oriented Architecture.

Transitioning from doing to managing

One of the hardest things to do in life is to make a successful transition from doing something to managing that same thing. The temptation to roll up one's sleeves while managing the process is simply too strong to resist. And that's why not too many people end up being good management material.

In the world of software development, right now there is a huge demand for people who are capable of abstaining from rolling up their sleeves and instead delegating the responsibilities to the 'workforce' out there.

What does that mean? In a more technical parlance, it's been proven that once software developers get trained in making procedure calls when attempting to process some information, they tend to get addicted to that gateway drug. Similar to how to a person with a hammer everything looks like a nail, to a programmer who had learned how to make procedure calls, every information processing challenge looks like a string of procedure calls. This algorithmic frame of mind is very hard to get rid of, once a person gets it contracted. And in order to become an efficient web developer, each and every procedure-besotted person must learn to let go of the procedure call driven world view.

Transitioning from local to distributed procedure calls

Most people learn how to program computers by implementing procedure calls that are local. What that means is that their world view is CPU-centric. In other words, the executable code in its entirety is sitting on a local box, usually right next to the developer's desk. The developer then intuitively grasps the world as consisting of a single Central Processing Unit which acts as a traffic cop, deciding on who gets to do what and when. The 'who' in the previous sentence refers to the procedure. Typically, a programmer will modularize his code into a fairly large number of procedures. These procedures will then be called at opportune moments, will perform the intended processing, and will then recede in the background.

This situation is the prescribed way for teaching newcomers how to develop software. It willfully ignores the real world issues, such as that there is very little use and need in having a 'desert island', 'single sink' scenario, where a computer user will be sitting alone engaged in the 'glass bead game' on the computer. In the world of business at least (and also in the world of entertainment), multiple users are a must. Meaning, CPUs and people will be networked (999 times out of 1,000).

There inevitably comes a time when a software developer wannabe realizes that a transition from a single CPU to multiple CPUs connected via the network, is unavoidable. At that point, the newbie usually gets struck by the immense complexities that such transition entails. And it is at that point that the newbies all over the world decide to drag in the procedure call world view into the networked world.

Now the problem of control in a multi-CPU environment arises. Who's in charge here? It used to be that a single human mind was in full charge and control over the execution of computing instructions, via the single CPU. Now, all of a sudden, multiple CPUs which are distributed across vast networks enter into the equation. The remote nodes start posing the problem when it comes to controlling the proceedings.

The only way for such developers to try and tame this complexity is to wiggle in their chairs and to fabricate some hairy-brained scheme for enabling remote procedure calls (or, RPC). Various mind-boggling protocols get implemented (CORBA, RMI, DCOM, SOAP, SOA, etc.) All of these protocols are incredibly arbitrary, non-compelling, frighteningly complex and brittle.

As we can see, this transition from making local, simple-minded procedure calls to making distributed, remote procedure calls never goes well. In the end, it inevitably results in fragile, brittle software that requires constant duct-taping and chewing-gumming in order to stay afloat.

Who's going down with the ship?

It is obvious to even a casual observer that the majority of software projects, today as in the past, fail miserably. As the complexities of the business scenarios continue to increase at a frightening rate, this rate of failure will only skyrocket.

At this pace, it won't be long before the software development industry turns into another Titanic, if the majority of developers continue to charge down the remote procedure call path. Developers who refuse to go down with the ship have only one option -- abandon the RPC ship and hop into the ROA boat.

But as we've already seen, the transition from navigating a huge, unwieldy ship to rowing a tiny nimble ROA canoe is proving more challenging than most developers are prepared to bear. That's why there must lie a major shakeout ahead of us, a shakeout that will separate the monolithic totalitarian software practices from the nimble, distributed ones. And ROA practices are certainly on the opposite side of the monolithic remote procedure calls practices.

How to make the transition?

It seems to me that, in the process of making the transition from RPC to ROA, the biggest stumbling block for the entrenched software developers lies in the fact that ROA proposes erecting an impenetrable barrier between the client and the resourses on the server. In the bad old RPC world, such barriers are unheard of. In other words, if the client is privy to the protocol that the service-oriented server had arbitrarily and unilaterally made up, the client can intimately manipulate the state of the server.

No such thing is ever possible in the ROA world. And that's the biggest put off for the honest-to-god procedural crowd. They simply don't seem physically capable of conceiving the world where it would not be possible to 'crack the code', learn the protocol, and then rule the server on the other end.

So in order to make a successful transition to ROA, these software dictators must learn how to abdicate from their dictatorial throne. What are the chances of that happening en masse any time soon?

Slim to none? What do you think?

Wednesday, August 15, 2007

Resource Representation

Software developers seem largely incapable of understanding the difference between resources and their representation. Understanding that difference is absolutely vital in understanding REST and the Resource Oriented Architecture (ROA).

Is it a small wonder then that we are beginning to see articles like this one ("Why is REST so hard to understand?") pop up in the publications devoted to the web architecture? It is absolutely clear that we won't be in the position to advance ROA practices unless we reach a critical mass of people who do possess a solid grasp of what is the difference between a resource and its representations.

Right now, it seems like only an infinitesimally small percentage of software developers are aware of the significance of that difference. For example, if we say that there are ten million software developers worldwide, 9,999,000 of these developers are blissfully ignorant that such a thing as resources and their representation even exists. Which leaves us with only about 1,000 developers who truly understand what it all means. Not a very encouraging statistics. As a matter of fact, the situation today is right down dismal.

We need to do something quickly in order to remedy this catastrophic situation. My small contribution here is to attempt to clarify the difference between resources and their representation. I will use mostly concepts from everyday life for illustration purposes. I will then attempt to draw the parallel between these concepts and the concepts one encounters in the arena of software development.

What is a Resource?

Let's start from the top: a resource is anything that humans find useful. For example, a house might be a resource. Or, money might be a resource. We find houses very useful, because they offer certain level of comfort in our daily living. We also find money very useful, because it's a resource that enables us to get other resources, such as houses.

Ten years ago, when I was buying my first house, I wanted to see what kind of a house can I afford. To that end I met with a mortgage broker, who interviewed me in the attempt to assess my buying power. Among other things, he needed to know how much money can I allocate towards the down payment on the house.

Once I told him how much money I have for the down payment, he was able to plug that information into his spreadsheet and then tell me what kind of mortgage do I qualify for. So I was then all set to go out and shop for the house, right?

Well, not so fast! Just because I've blurted out a dollar figure that I had in mind for the down payment, didn't automatically mean that I fully qualify for that mortgage. Because, you see, my word in these matters was viewed as being largely subjective, that is, prone to miscalculations and all kinds of other aberrations. What the bank needed is a more objective assessment of my buying power. Talk is cheap, and anyone can claim that they have one hundred thousand dollars tucked away in their bank account, ready to be plopped in toward the down payment, but the reality might be somewhat different.

Because of that, the banks have devised a more impartial practice, whereby the applicant must provide what is deemed to be a more objective proof that the money really is in the applicant's bank account.

In this example, the money that has been allocated for the down payment on the house is regarded as a resource.

What is a Representation?

Now, the down payment money we are talking about may indeed be sitting in my bank account. But how am I to truly convince the mortgage broker that it is really there? Well, I use the means of representation, that is to say, I use something else that acts on behalf of that money. For example, I use my words to convey the fact that I do have $100,000 in my bank account. My words then represent my money.

But, as we've seen, that representation (my words uttered in a casual conversation) is apparently not good enough for the mortgage broker. He needs something more 'solid' before he is fully convinced that the money is actually there. Meaning, he needs a different form of representation.

Typically, what the mortgage broker would deem a fairly impartial and objective representation of my money is a piece of paper issued by my bank that claims that it is true that I do have $100,000 in my account. In other words, once the mortgage broker receives that piece of paper, he can 'take it to the bank', so to speak.

That piece of paper is what we call a representation of a resource. The real money is nowhere to be found in that representation, yet in a somewhat superstitious manner, all the parties involved almost religiously obey and agree that a piece of paper is as good as the real thing.

Back on the Web

The exact same protocol abides on the web. There, as in everyday, non-virtual life, we have resources which are tucked away somewhere, and all we get to see, feel and touch are the representations. Resources on the web are merely concepts that are being represented using other concepts. On the web, as in real life, no one ever gets to see, hear, feel and touch a resource. All we get is mere representations.

We are free to attempt to manipulate those representations. And even in the cases when our manipulation yields perceptible differences, we have no grounds to claim the we have actually manipulated the resource itself. All we can conclude is that the resource representation has changed under the influence of our actions, nothing more, nothing less.

For example, if there is a resource such as a volleyball tournament published on the web, I can get its representation by sending a request for it. I may then decide to destroy that tournament by manipulating the tournament's representation. And my action may result in an affirmative representation (i.e. the resource may respond by sending me its representation which states that it has destroyed itself). I may then conclude that the volleyball tournament has, indeed, been destroyed. But I really have no way of ascertaining that. All I can claim is that I have acted upon the initial representation of that volleyball tournament, I have sent it the request to destroy itself, and I have received the confirmation that it is now destroyed. However, the resource itself may still be alive and well, existing somewhere beyond the reach of the resource representation. The only thing that is manifestly certain is that from that moment on, the resource will refuse to render its representation for the incoming requests.

This is similar to how, in the real world, no one would ever suggest that I take the mortgage broker into my bank's safety vault and point him to the pile of cash that's sitting there, and tell him: "Here, here's my $100,000, please count them and let's get on with it!" No one goes straight to the resource itself in real life, and the same holds true in the digital life as it gets distributed on the web (not to mention that even the physical cash is merely a representation of some other concept, etc.; one can never possibly get to the bottom of it, that is, the real resource is nouminal, unreachable by us mere mortals).

Understanding this distinction is vitally important if we are to move forward successfully in building the functional web of information. It is my experience that none of the developers I've ever worked with understand this situation, and that all of them erroneously believe that they are, at all times, working with the 'real thing'. Nothing could be farther from the truth, so I implore all developers to take a moment and try to digest the difference between resources and their representations.

Thursday, June 14, 2007

Software Development Detox Part 4: Tribal Computing

One of the absolutely most heinous types of software intoxication is what I like to call Tribal Computing. This is the form of computing that is tied in with the primitive, proprietary setup and is a remnant of the old days of early adoption of computing by the businesses.

Ontogeny recapitulates Phylogeny

Ernst Haeckel (a German natural historian) wrote in 1868: “Ontogeny, or the development of the individual, is a short and quick recapitulation of phylogeny, or the development of the tribe to which it belongs.” (in this context, ontogeny is the development of the fetus, and phylogeny is the evolution of a species). Haeckel was referring to the way the fetal development of mammals seems to parallel the evolution of all life on earth. The fertilized mammalian egg first resembles a single-celled amoeba, then a multi-celled sponge, then a jellyfish, then an amphibian, then a reptile, then finally becomes recognizable as a mammal.

Applied to the field of computing, one could say that the development of computing seems to parallel the development of human society. At first, the society was segmented into small primitive tribes, which slowly evolved into larger units, such as cities, counties, provinces, regions, countries, nations, and so on.

We are today standing on a threshold of global computing (i.e. the web). But, in certain ways, we still seem deeply entrenched in the primitive, stone age world of tribal computing.

Think Locally

Most software in operation today is severely localized. Meaning, it was built to live on a single box, single CPU. Everything about it is very closed, very proprietary, and extremely local.

Some software allows for certain level of connectivity, whereby other software systems are given an opportunity to connect to the localized software and share/exchange some information.

Only the latest, most recent batch of software products (the so-called social software) has left the world of tribal computing and is reaching out to the global computing space.

Control Locally

Most tribal software was/is built with an engineering frame of mind. Whenever we approach building something with an engineering outlook, we are striving to introduce maximum level of control into the system.

One of the most detrimental side effects of building software with an engineering slant is the temptation to retain the state of the conversation. As we've seen in our first installment (State), the best way to create brittle and buggy software is to insist on retaining the state of the conversation that had transpired during the operation of the software product.

In addition to that, insisting on staying local (i.e. tribal, single box, single CPU etc.) means that the point of control also stays tribal. There is a single authoritative instance that claims to know everything and that controls what can and cannot happen on the system. That instance then becomes a single point of catastrophic failure.

Relinquish the Control Globally

In contrast, non-tribal software exhibits stunning capabilities for growth thanks to relinquishing the rigid engineering attitude. One of the fundamental reasons why web is such a spectacularly successive computing platform lies precisely in this abandoning of the tribal past and moving beyond the need to control and retain the state of the conversation.

By deciding to not care about the state of the systems engaged in the conversation, the non-tribal, globally oriented software is free to grow in any direction and to scale to any level of complexity.

We will see in the next installment what are the most optimal ways to achieve that level of robustness. Stay tuned.

Tuesday, May 29, 2007

Software Development Detox Part 3: Join the Conversation

So far we've established that the unsophisticated software solutions tend to be brittle and unreliable due to the following erroneous decisions:
  1. Keeping track of the state of the conversation between the client and the server
  2. Choosing to expose services through messaging interfaces (a.k.a. Remote Procedure Calls)
Today we're going to look into the minimal requirements for establishing the platform for enabling successful implementation of the business computing. We will see how important it is to separate the state of the conversation, that may have transpired between two or more business parties, from the transformations of the state of the participating parties. Also, we'll look into the advantages of abandoning the messaging interfaces when conducting business conversations.

Sustainable Business Strategies

Abandoning the world of software for a moment, let us examine the strategies that facilitate success in the world of business. Experience has shown that short term success is certainly achievable by exclusivity (i.e. by locking customers into some sort of a proprietary business model). However, for achieving any level of sustainability, businesses must, willy-nilly, open up and introduce free choices and embrace diversity.

In order to attain happy equilibrium of a sustainable business growth, one component of the business interaction must be optimized -- conversation. Businesses thrive on open-ended conversation. What that means is that while initially only two privileged parties may begin business conversation, other interested parties should be able to join and participate at any point.

For that to happen successfully, the barriers to entering the stream of conversation must be placed extremely low. In practical terms, anyone interested in joining the conversation should not be expected to learn any arbitrary set of rules, any new language, or any new protocol.

In addition to this fundamental requirement, parties joining the conversation midstream should also be able to easily examine the history. Anyone joining the conversation should be able to immediately gain access to the 'minutes' of all the previous conversations. That way, an interested party could, at their own convenience, examine the minutes and learn about some vital stats of the ongoing business transactions.

These two (the ability to join the conversation at any point in time and the ability to examine what had transpired up until that moment) are the most vital and essential requirements for conducting successful, sustainable business transactions.

Sustainable Business Computing Strategies

When it comes to achieving sustainable levels of business computing, the challenges tend to be even greater. Computing infrastructure and practices, that are being placed between various business parties interested in joining the conversation, serve to raise the barriers to entry.

Still, the promise of information technology is to make those barriers even lower than they tend to be for the non-digital business interactions. And in all truthfulness, that really is the true calling of this technology. So, the question then is: what went wrong?

The simplistic answer to the above question is that someone along the lines made a couple of wrong decisions (see the erroneous decisions listed above) and created a complicated situation resulting in businesses being unable to join interesting and potentially profitable conversations that are happening online.

Our job, then, is to remedy this situation, and to bring the technology back to the level where pretty much any interested business party is capable of easily joining the conversation. Not only that, but any party should qualify for easily examining the history of the conversation by replaying the 'minutes' of what had transpired while they were away.

Simplifying the Medium

In the world of information processing, bits and bytes could represent anything. But in the world of business computing, the medium that is of most interest is text. So in most situations, what is of particular business interest is content that is rendered as text.

Of a much lesser significance, but still figuring rather prominently in the world of business computing, are images. Less prominent media types would be audio and video.

So the viable computing platform that would fully facilitate successful business conversations is mostly focused on the content rendered as text. That content should be marked up in order to achieve certain level of semantic order. But the markup shouldn't be blown out of proportions.

Simplifying the Protocol

Once the medium for exchanging business content is sufficiently simplified, we must make sure that the channels for communicating that content are also fully simplified. Instead of expecting any interested party to learn the intricacies of a foreign language that is unilaterally enforced by the vendor, we must offer a severely restricted list of possible actions that are publicly vetted and extremely non-volatile.

For any resource that the businesses may be interested in, we can safely establish that only four actions would suffice when it comes to maintaining that resource:
  1. Add resource
  2. Remove resource
  3. Modify resource
  4. Fetch resource
The above four-pronged protocol is sufficient for conducting any business conversation. No further elaboration on the business computing protocol should ever be required (there is no need for any kind of messaging interfaces).

Joining the Conversation

When an interested party learns about the ongoing business conversation and wants to join in, all it has to do is fetch the state representation of the resource in question. From that point on, the interested party is free to propose any transition of the state of that resource. In addition to that, the interested party is also free to replay the conversation as it had unfolded prior to joining the conversation.

The above scenario is universal, and it applies across the board. Following this model, we can ensure that any business parties will have a successful transition to participating and contributing to the ongoing stream of business conversations.

Software Development Detox Part 2: Remote Procedure Calls

We've seen in our first detox installment that it is detrimental to maintain the state of the conversation between participating parties. The conversation that may have occurred between the interested parties and a targeted resource may have affected the state of the targeted resource. But that doesn't mean that the various stages of the conversation itself need to be retained.

Today we'll look into another form of software intoxication; this one has to do with how is the conversation implemented.

Typically, when two or more parties get engaged in a conversation, they tend to accomplish successful conversation by sending each other specific messages. For example, if an airplane is approaching the airport, the messaging between the pilot and the control tower gets peppered with code words such as "roger" and "over". That way, the conversation protocol gets established in the attempt to minimize the noise and maximize the signal.

In a loosely coupled world of business computing, free market forces dictate that many solutions providers can compete for the most successful solution. That situation creates a wild diversity of proposed conversation protocols. What's happening is that basically any vendor (i.e. solution provider) is free to come up with a completely arbitrary set of formal rules outlining how is the conversation going to take place. That creates a hell of a noise in the solution space, resulting in brittle and faulty implementations.

The culprit most of the time boils down to the methodology known as Remote Procedure Call (RPC). The remote procedure proposed by the vendor is a completely arbitrary, unilaterally constructed expression that the vendor expects the consumer to learn. In addition, the vendor reserves a unilateral right to change the expression encapsulated at the RPC level, and the consumer has no recourse but to re-learn the intricacies of how to talk to the vendor.

This unfortunate situation creates endless problems and headaches. All the consumers of the proposed vendor services are expected to keep an ever growing inventory of those custom Remote Procedures, and are on top of that left vulnerable to the future changes of that inventory.

Because of that, the effective detox therapy strongly advises against using the RPC model when architecting and designing your software solution. We will see in the next installment what is a much better way to go about accomplishing the robust software architecture.

Saturday, May 26, 2007

Software Development Detox Part 1: State

In the first installment of the software development detox program, I am going to review misconceptions and misunderstandings of one of the most fundamental software concepts -- state.

The problem with understanding state in the context of information processing/software development arises when people fail to recognize and acknowledge that there are two distinct aspects of state in the arena of software development. By bundling up these two aspects, people end up projecting an incorrect picture and consequently paint themselves into a corner by choosing the unsuitable architecture.

I am now going to (temporarily) abandon metaphors (such as 'paint oneself into a corner' etc.) and switch to using simple, albeit somewhat exaggerated examples.

Software Types

In this example, I am going to review a common occurrence of a typical software construct, such as date. Date is an abstraction devised to encapsulate and express human concept of time. In the world of information processing, we use software constructs, such as types, to encapsulate and express abstractions such as calendar date.

Suppose someone offers a software abstraction (i.e. type) called CustomDate. This abstraction is supposedly capable of doing accurate date calculations, and is endowed with certain conveniences. One such convenience being the ability to express, in calendar terms, such human concepts as 'tomorrow', 'yesterday', 'next week', etc.

So we see that this type is capable of certain behavior (such as being able to answer the question 'what date is tomorrow?', etc.) But, in addition to discernible behavior, software types typically also possess state. For example, our CustomDate may possess a state of knowing what date is year-end.

This state may change (different corporations have different year-end dates). And the instance of the type is expected to remember the changed state.

What can you say and how it gets interpreted

Upon acquiring a new software type, such as CustomDate, we will be expected to learn about its capabilities. We are not expected to understand how it is working. We're not even expected to understand all of its capabilities. We are free to pick and choose.

For example, if the CustomDate possesses 50 different capabilities, and all we want from it is the ability to tell us what date is the year-end, we should be able to safely ignore the remaining 49 capabilities.

To violate this basic agreement would result in creating brittle, unreliable software. Here is one fictitious example that illustrates this problem:

If we instantiate CustomDate and assign that instance a handle such as customDate, we should then be able to talk to that instance. If we are only interested in learning about our company's year-end date, we can send a message to our customDate instance, as follows:

customDate.year-end

In response to receiving that message, the customDate instance will return the actual year-end date to us.

The above described scenario should always yield the same behavior. There shouldn't be any surprises in how an instance of customDate behaves upon receiving the year-end message. If there is even a slightest possibility that the established message may render different, unexpected behavior, our software is not only brittle, but extremely buggy.

By now you may be wondering how could there be a possibility that the above scenario ever yields any different behavior than expected? Let me explain with another example:

We've learned so far that, when dealing with an instance of customDate, we can say year-end and it will be interpreted as a question that reads: "could you please tell me what is the year-end date?" Consequently, the representation of the correct year-end will get rendered and served as a response to our query. We've thus realized that an instance of customDate has state. That state (i.e. the actual value of company's year-end date) is the only state we're interested in when dealing with this software construct.

However, as we've mentioned earlier, this software construct may have 49 other capabilities and states, of which we know nothing. Now, the fundamental principle of software engineering dictates that we are absolutely not required to know anything about any additional, extraneous states and behaviors that a software construct may bring to the table.

Regardless of that prime directive, people who are not well versed in designing software solutions tend to violate this dictum on a daily basis. The way to violate the prime directive would be to introduce certain state/behavior combo that will modify how the question gets interpreted. One can imagine how easy would it be to add a capability to CustomDate which will turn it into a currency conversion utility. This example is admittedly unrealistic and exaggerated, but I chose it to illustrate the foolhardiness of arbitrarily assigning various capabilities to a software construct.

In this example, an overzealous green developer may add a capability to CustomDate that will put it into a "currency conversion" mode. If someone else is using the same instance of CustomDate and puts it into this "currency conversion" mode, that change in its state may modify the behavior of an instance of CustomDate, rendering the response to the year-end question unintelligible.

Let's now run this hypothetical scenario:
  1. CustomDate gets instantiated as a resource on the server

  2. A message arrives from a client asking the resource to convert 100 USD to Canadian dollars

  3. An instance of CustomDate (i.e. customDate) puts itself into the "currency conversion" mode and renders the proper currency conversion

  4. The client then sends a message to customDate asking it for a year-end

  5. The instance renders an answer that corresponds to the value of 100 US dollars at the year-end
The above answer at step 5 comes as a complete shock to the client who asked for a year-end; the client wasn't aware that the instance can be shape-shifting and consequently may not always be returning dates when asked about the year-end.

In other words, what you can say and how it gets interpreted changes based on the state that an instance of the type may be in. A very bad situation, guaranteed to render that particular software program dysfunctional.

Statelessness

We can see from the above example how disastrous it can be to attempt to manage the state of a resource. In our case, we've been managing the state of an instance of
CustomDate, keeping track of when is it a date rendering machine, and when is it a currency conversion machine.

This tracking of the state resulted in the breakage of the working code. If we had abstained from keeping track of the state of the instance, the problems wouldn't have emerged in the first place.

From this we see that the only way to achieve robust and reliable software is to ensure that its constituent components are stateless. No memory of what had transpired during previous conversations should be retained.

However, keep in mind that we must distinguish here two types of states:
  • Entity state
  • Conversation state
It is this conversation state that is troublesome. Entity state is perfectly valid, and should be memorized. In this instance, entity state would be the fact that our company's year-end is October 31.

Keeping track of what transpired as clients have interrogated an instance of a software component, and then retaining that state, is always disastrous. And yet that is how most inexperienced software developers tend to architect and design their software.

Coming up

In the next installment, we'll look more closely into how to architect and design stateless software.