Simon’s Blog

As anyone involved in building software in a commercial environment knows: developer productivity really matters. Of course, amongst developers there is a huge range of capabilities: great developers can be more than ten-times as productive as average developers. And not only do developers have different intrinsic abilities, they like to work in diverse ways. So, enabling developers to maximise their productivity is not a simple issue.

To help me think about the issues surrounding developer productivity, I use a model. No model is perfect, of course: this one has the advantages of being both simple on the surface while also being able capture some of the complexities too. The model borrows from the subject of physical chemistry: specifically the field of reaction kinetics. The benefit of borrowing established theories from other fields, is that the ways different models behave has already been worked out. It turns out that the rate of one of the simplest types chemical reaction can be expressed as follows:

rate = k[A]

where [A] means the concentration of one of the reactants; and k is what’s known as a “rate constant”. The value of k, as you might expect given its name, is a constant, and its value contains information about intrinsic properties of the system (it tooks many years of research for people to understand what those were). The theory of kinetics can be applied to the concept of developer productivity in several ways, but here’s one:

rate = k * (lines of code)

Thus, in this model, the rate at which a developer produces software is directly proportional to the number of lines of code they have to write. Some developers may be able to write a thousand lines of good code a day; and others may be able to write two hundred. This fact is captured in the rate constant, k. But, remember, rate constants are all about intrinsic properties - in this case, of developers. So, how can developers make themselves more productive, given their intrinsic capabilities are pretty-much fixed? The answer is: get the job done with fewer lines of code. Actually,”lines of code” is probably not the best way to express this idea. A more accurate equaton might be:

rate = k * (amount of typing)

In other words, the rate at which you can write software is proportional to the amount of typing you have to do. So, the way to increase your productivity is to get the job done with less typing.

So how do you do less typing? There are a few ways: use a language with a terse syntax; use a graphical IDE; use a great text editor. Which is best? Now, there’s a question! There’s no one “right” answer. Historically, what I would call “top-talent” developers have preferred great text editors, like emacs, over graphical IDEs, such as Visual Studio. Conversely, mediocre developers have favoured graphical IDEs over vanilla text editors. This is typically mirrored in other aspects of using a computer - you’re either a “command-line” person, or a “windows (with a small “w”) person). Command-line folks typically being more technically savvy than the windows folks.

A large part of the value graphical IDEs used to be to do with the fact that mediocre developers could make little or no progress when faced with a blank window in a text editor - in a similar way to some people not being able to think of anything to write when faced with a blank sheet of paper. The graphical IDE provided a framework which allowed them to “fill in the blanks” - witness the massive success of Visual Basic over the years. However, top-talent developers have never had that problem; and they found, for many reasons, that they were more productive with editors like emacs.

Now, if you believe the above equation is a complete model, then you would also say that great developers would also use only languages with super-terse syntaxes. After all, a terse syntax means less typing. Indeed, many people believe that; and it is - to some extent - a valid point of view. However, I would assert that the above isn’t a complete model. In general, developer productivity isn’t first-order. A better model might be a second-order one, something like:

rate = k[amount of typing][manage complexity]

What I mean by this equation is that the rate depends not only on the amount of typing the developer has to do, but also the degree to which the developer can manage the complexity of the system they’re building. With this new factor introduced, the terseness of the language the developer uses isn’t the only thing that’s important in general. What also matters is whether the language helps them manage complexity. As a simple example, you could say that an object-orientated language helps the developer manage complexity better than does a procedural language. Now, second-order reactions like the one above can become what’s known as pseudo first-order under conditions where one factor dominates over the other. So, for simple problems, where managing complexity is not an issue, the model becomes:

rate = k’[amount of typing]

where k’ is the pseudo first-order rate constant. The model suggests, then, that for simple problems, the terseness of the language is more important than in the case of complex problems (assuming the less terse language helps the developer manage complexity). Whereas, for more complex problems, the terseness of the language isn’t the dominant factor. Furthermore, in cases of extreme complexity, the model suggests that the amount of typing a developer does isn’t important at all. Rather, it’s all about managing complexity:

rate = k’[manage complexity]

Now, to return to the subject of of text editors versus graphical IDEs. I’ve been an emacs (and subsequently an xemacs) fan for around fifteen years. However, I’ve always felt that graphical IDEs have always held greater potential than simply to be of use to mediocre developers. Until recently, though, they just haven’t cut it as far as great developers go. Today, we’re at a crossroads. For developing in Java, at least, the current leading IDEs - Netbeans and Eclipse - now behave in ways that are useful to top talent developers in terms of productivity. In fact, they’re now more productive environments than vanilla text editors.

There’s no doubt about it. Today, if you care about productivity - both in terms of reducing the amount of typing you have to do, and being able to manage complexity - a modern graphical IDE is the way to go…