Ethical Software by Alex Bunardzic

I’ve recently had several opportunities to consult on some Rails projects, mostly in an advisory role. Meaning, going into the project after the bulk of the code has already been poured, and then reviewing the code and commenting on it, or suggesting alternative/more appropriate solutions.

It’s not an enviable position to be in. For several reasons. One, you obviously don’t want to hurt anyone’s feelings. It’s easy enough to be a critic, and there is frequently very little value in doing that. Two, once the concrete of the application code has been poured in and proven to ‘work’, it gets extremely difficult to justify refactoring it in any meaningful way.

Most of the time, it’s ‘let the sleeping dogs lie’ kind of a deal. Yes, the code is not perfect, and yes, there’s plenty of room for improvement, but you know what, let’s leave that for the next project.

All this being said, I still have a bone to pick with one thing I keep seeing over and over again: overzealous and uncritical use of Ajax in many Rails applications. That’s what I’d like to chat about here.

Reclaiming the Client State

The really great thing about the Javascript/Ajax movement is that it allows us to reclaim the client state on the client itself. What this means is that, for basically very minimalistic investment (amounting to ‘please do not disable Javascript on your client!’ plea), we get to offload the client state and thus unburden our overworked servers.

Before Ajax became entrenched, our application code had to work overtime emulating the state of each and every client hitting it. There could potentially be hundreds, if not thousands of clients buzzing around our application server’s memory. Typically, each of these client ‘avatars’ were represented as a cluster of objects instantiated in the application server’s memory. And these ‘avatars’ were not just passively sitting in the server’s memory. No sire-Bob! These ‘avatars’ know how to behave! Meaning, they keep sending and receiving messages, and in the process keep creating more and more objects. Before you know it, your server’s memory becomes chock full of these ‘avatars’ who keep behaving as if there is no tomorrow.

What that means is that there typically is an enormous pressure on your application server (or, cluster of servers), to hyperventilate and work like a madman. These beasts ended up being overworked. And in the process, they forced us to keep throwing in more and more resources.

Well, now there is a way to abandon all that and to relieve these poor overworked servers. If we simply find a way to abandon emulating the client state on the server, the need for hosting thousands of ‘avatars’ who behave and grow will then diminish.

And that’s exactly what’s happening with Ajax. Instead of expecting our server-side application code to emulate the clients and to incarnate them in the form of ‘avatars’, we simply push that responsibility to the clients themselves. Any client who can execute Javascript can now take care of its own state and behavior.

Trouble in Purgatory

Not all is rosy, however. This ‘manage client state where it belongs — on the client’ dictum turned out to be a double-edged sword. Its downside is that it tends to violate some basic principles of web-based computing.

For starters, web is a computing medium that owes its phenomenal success to the fact that it can fake things. For example, the web can fake state. Even though it is stateless (by design, and rightly so), the web allows us to pretend that there is such concept as session. But in reality, there isn’t.

Similarly, the web can fake client’s state. Even though the web itself was not built with such thing as ‘client state’ in mind, it allows us to utilize certain hooks to pretend as if client state is built into it.

Lighthearted things, such as cookies, hidden form fields, URL redirection, are the simple tricks we all use to create this make-believe world where it appears as if the web comes equipped with sessions and client state etc.

All these tricks work great, and are in perfect accordance with the web spirit. So, what happens when we begin to mess with this simplicity?

Mixing Oil and Water

Oil and water do not mix. You can force them to appear as if they’re mixed (but only temporarily) by shaking the mix of oil and water vigorously, thus forming an emulsion. But pretty soon the illusion disappears, and water goes to the one side, oil to the other.

Same goes for the single-sink vs social software consideration. It would not be possible to develop an efficient social software product which would be built on the principles of the single-sink software.

So we see that mixing oil and water in this context means that we cannot efficiently mix desktop and web paradigms. All kind of problems ensue when we attempt to build a web app that should behave as if it’s a desktop app. And vice versa.

And yet, that’s what Ajax-colored approach seems to advocate. Bring back the desktop paradigm into the world of web. That’s not the wisest thing to do, if you ask me.

Where’s the Problem?

Why make such a big deal out of desktop vs. web, single-sink vs. social software? Can’t we all live together in harmony?

Yes we can, but only providing that we understand exactly what we’re doing. Which apparently is not very likely to happen.

So why is it not likely that we understand what we’re doing? I’d say it’s probably because we don’t fully understand (yet) the true nature of social software. And that’s why we can’t see very clearly how desktop-oriented (i.e. single-sink) software violates the principles of social software.

Consider the following: when we’re working in a desktop, single-sink mode, we go through the cycle of consuming the application services, but we don’t share that experience with anyone. Which is why I call that a single-sink experience.

But as soon as we start using social software, the experience is shared. And that means that it is transferable (up to a point, of course).

So how do we transfer the experience in the social software world? Simple — by bookmarking it and forwarding the bookmarks!

Notable and Transient State

As the experience of using a software product unfolds, there are milestones that not only deserve to be noted, but also force us to jot them down. These ‘milestones’ denote significant state of the system The behavior of the functional system is governed by the rules that ensure that the transition between notable states is safe.

There are also numerous not-so-notable states that we go through while experiencing a software product. We call such states transient. These states do not deserve to be noted or stored somewhere.

It is extremely important to realize (especially if you a re a web developer/web designer) that Ajax should only be used to govern/render the transient, non-notable state. If the state transition is significant, and i it yields a ‘milestone’ state, then using Ajax would be completely inappropriate.

This simple rule of thumb will get you safely to the other shore. The trick is not only to keep the transient vs. notable state in mind, but also in identifying states that truly deserve to be notable. The challenge is that most of us cannot be clear, most of the time, which state is transient, and which is notable. Only good analytical and design skills will ensure that these states are successfully and properly identified.