If you talk to Rubylosophers, you’ll get some hip and hippie discussions of how languages should be designed for harmony and balance, to make programmers happy. When faced with a Rubygmatic programmer, words like ”productivity” and ”rapid development” will be heard. However, those seem almost magical, and are pretty hard to base a hard decision on unless you’ve experienced them yourself.

In this post, I’ll explain a simple model that I’ve come up with over the years, as I experienced a fair (though by no means vast) variety of languages. Please note that it’s only a model, and it’s not meant to explain everything under the sun. It’s simply a metaphor that I use when describing why language X is better than language Y to someone who doesn’t get programming. If you push and pull at it enough, it will crumble. But before it does, it can still be used to derive some interesting insights. I hope it is useful to others too.

Since I’ve come up with a number of interesting insights from this model, I’m going to split this article into multiple parts, probably about 3.

The basic model

The key piece of thinking behind this model is the idea that as a program ages and more functionality is pinned onto it, it develops something I like to call “viscosity”.

What is programming viscosity? It’s the almost imperceptible (at first) slowing down of the speed at which change can occur, due to the risk of causing unforeseen bugs. It’s not a new concept, nor is it only applicable to software. In ”Developing products in half the time”, which has nothing to do with software, the authors argue that each feature increases the complexity of the system in an exponential manner (because each new feature adds N possible interactions to the product, where N is the number of existing features). That is largely true for software as well, but in a much more pernicious way.

Software products are inherently vulnerable to scope creep, much more so than physical products, because “customers” (be they clients, or business users within your company), have an intrinsic understanding that adding more buttons to a physical object makes it more complex, but they don’t have such a direct understanding of why the same is true for software (a whole article could be written about why that is).

Now, viscosity in software products is never actually infinite. It’s always possible to make changes. However, the viscosity may well become so large that each change ends up taking a huge amount of time. When that happens, change freezes because it’s too expensive. Not only that, but as the complexity increases, it becomes more difficult for programmers to deal with it. Either they get irritated and bored by it, in which case they’ll figure out a way to get out of your project and move elsewhere, or they simply can’t cope with it anymore, and then you get a situation like that described in this article, where you need a vastly better programmer to come in and sort out the mess (effectively rewriting half or all of the system in the process). If you don’t have access to one of those great programmers when that happens, you’re stuffed. If you do, you may still be stuffed, but at least you have a chance.

This state of high viscosity is, in my experience, inevitable. No matter how smart your programmers and how fantastic your language, they’ll eventually reach it, unless your project is really trivial (e.g. an online company brochure). All non-trivial projects accumulate features over time and get harder and harder to work with. The question is, can you push this point back until you can actually afford a major rewrite? If you pick the wrong language, what’ll happen is you’ll reach that point too quickly, before you’ve shipped your product and started taking in cash. And then your business will sink. Even if you have vast amounts of money available to patch things up, you want to push back that point as far as possible, because a Big Rewrite is always a costly and risky manoeuvre, with no guarantees of success.

Without further ado, here’s the basic graph showing what I’ve been talking about.

There’s only one new element that I haven’t talked about in this graph, and that’s the Boredom Limit. What this limit means is quite simple: beyond this point, your programmers will lose interest. They’ll still work, maybe even work hard, but it’ll be something other than the love of coding something cool that keeps them at it (good examples might include: financial bonuses, personal commitment, enthusiasm for the business idea behind the project). Even if they continue to work on the project, there’ll be a nagging voice inside telling them they’d rather be doing something else, and that will start to take its toll as time passes. This extra cost won’t kill your project, but you should be aware of it so that you can ensure those additional incentives are in place - otherwise your programmers will just leave.

So, let’s draw a first insight from this graph.

Insight 1: Comparing languages

Let’s represent more than one language on this graph. Each person might have their own opinion about languages. The comparison below represents my experience with 3 fairly important technologies used to develop web applications: Java, PHP and Ruby on Rails.

There are basically two factors at play here: the initial overhead, which increases the viscosity right from the get-go; and what I’ll call the “viscosity function”, which is the speed at which viscosity increases with time.

A framework like PHP has very little overhead at first, which is extremely good for very small projects that have extremely little chance of growing beyond that simple stage. For instance, a very lightly dynamic website with some simple forms would be very quick to develop in PHP, and slower to develop in most other frameworks. However, as the project grows, the viscosity of a PHP application quickly becomes unmanageable. Since all medium projects have a tendency to accrue extra features and become larger, I would not recommend PHP for anything that is likely to be more than a simple site with a handful of forms and dynamic elements.

At the other extreme, a language like Java, with a rock-solid framework like J2EE, has enormous up-front overheads. It takes about a week just to get your development environment wired up so you can get started on your development! By that time, the PHP project should already be finished and shipped. In From Java to Ruby, Bruce Tate quotes some engineering managers who claim that it takes at least 2 years to earn the adjective “experienced” in the Java world. And, from my personal experience, that’s true. There are many, many bits and pieces to learn in a framework like J2EE, and it takes an enormous span of time to acquire them all, and just as long to wield them effectively. On the good side, however, J2EE scales admirably well into the future, so long as it’s been reasonably well architected. Your development might be a pain, lumbering along like a snail right from the beginning, but you can rest fairly well assured that it will be a looong time before it slows down much more than that.

Finally, in the middle, a framework like Ruby on Rails provides a much, much better viscosity function than PHP, but with a much, much lower initial overhead than J2EE. Rails supports most of the useful J2EE patterns right out of the box, so that reduces the viscosity function quite a bit. It’s very quick to learn and be productive in (I started doing cool things with it practically from day one). So the initial overhead is low.

Placing these languages like that is only my opinion, of course. Feel free to disagree. However, this is the way I’d place them based on my experience of them.

That’s enough for this first article. I’m very keen to hear what others think about this model, so please leave some comments if you have some suggestions. Part 2 and 3 of this article will cover how this model can be extended to explain the effects of good and bad architecture, of development methodologies and of programmer quality (and probably a couple more things I haven’t thought of yet).

Thanks for reading.