For almost ten years now, I have been a jury member of the annual RAD (Rapid Application Design) Race. This is a nation-wide programming contest in the Benelux (here’s the link, a good opportunity to work a bit on your Dutch) in which teams of two developers have to create a working solution within 48 hours, using the tools set of their choice. A few years ago, the organizing committee decided to rename the contest to ‘Development Tools’, apparently to emphasise the importance of tools in productivity.
This could also be noted in the recaps of the races – published in a local IT magazine – that year after year focussed more on the features and peculiarities of each tool being used. The target audience of the magazine, software engineers, apparently just love to meander through the pro’s and cons of programming languages and development platforms. It’s an addiction, really. Just very recently, I witnessed yet another elaborate discussion unfold on e-mail, comparing JEE (Java Enterprise Edition) with .NET, trying to establish which platform was the most productive.
It just confirmed me again in what I already realised when I read the report of the most recent RAD / Development Tools Race: why writing piles of articles about the bells and whistles of tools where in-depth interviews with the winners and losers would have taught us so much more?

Let’s not beat about the bush: even in 2007 the success of a development project is still determined by the involved individuals and the dynamics between the team and its environment.
Of course you can use the coolest, newest programming languages available. You can build on the most extensive frameworks and design patterns. You may utilise code generators that will spontaneously start to produce code from hummed radio tunes. For all I know, you could even possess the best object-to-relational mapper in the world (good luck with that, come to think of it): the project still won’t run any better if the mix of people is wrong.
Only a few years ago, the winner of the RAD race was determined through the (American) Idol principle. The three members of the jury would sit behind the table and each team would successively show their results of two days of hard designing and programming labour. Believe me, many false notes were struck.
Some teams simply managed to produce nothing. I vividly remember a team that in the early years of Java didn’t even have a login screen functioning (with ‘Teach Yourself Java in 21 days’ opened at their desk, we already had some suspicions, admitted). But enough teams showed good, working applications with enough functionality. And then, the ultimate winner was not determined by who had the greatest number of ticks on the feature list. Much more, it was a matter of the overall perspective: an almost holistic view that the jury gradually would develop as a combination of the realised features, the aesthetics of the user interface and the architectural principles behind the solution. Also, an important difference was made by the way the team presented their results. Nervous stuttering or long, semi-autistic silences typically didn’t raise the confidence of the jury. But the winning teams invariably qualified themselves by putting all of their enthusiasm in a confident demo, always with a razor-sharp feeling for what the jury wanted to hear and see.
This method of judging has been modified a few years ago (at the same time that ‘RAD Race’ was renamed ‘Development Tools Race’). Today, a detailed checklist of required functions is the one and only starting point. The entirely objective jury members use it to determine step by step what has been produced. It feels like an Idols jury that only verifies if all the notes have been struck right, the lyrics were remembered well and the right dance steps were performed.
We all know that doesn’t work. Just adding up capabilities does not create a Pop Idol. Even so, during the acceptance phase of solutions development the client won’t commit to the end result if we just mechanically proof that all required functions have been realised. A project team that declares death to empathy and sticks obstinately to the agreed specifications stands no chance; users will always find some fatal objections if they just don’t grant the success to the team.
On the other hand, a team that manages to merge into its user community, living and breathing its perspectives, may expect a mild attitude and forgiveness. Even if some minor features are missing in the final result: it’s not only about the lyrics and the dance steps.
Think I will consider this blog-item as an open invitation to the organising committee of the Race next year: why not rechristen it “Development Idol 2008”? Less checklists, more interaction. Could be an instant hit.