niksilver.com

I thought I’d answer a question that comes up from time to time about the Java development and redesign work going on for the Guardian Unlimited site: “Why didn’t you write it in Ruby?”

I was reminded of this question because of an excellent post over at Manageability.org in which ceperez wonders aloud whether dynamic languages can scale. The post contains excellent thumbnail sketches of various languages, and the suggestion is that different languages cultivate different habits which have different consequences as an application (or project) evolves. The flipside of this question is Nati Shalom pondering why Java isn’t used more for large scale web applications. Nati’s post is one I’ve kept around for some time, wanting to follow it up, and so this post finally does that.

The question of why the Guardian Unlimited redesign isn’t taking place in Ruby is sometimes asked of me, but most often asked of any of our architects, often following a presentation of our work. Here are some answers.

1. A personal answer

My own immediate answer to the question is usually a reaction to the fact that it is too often asked by certain kinds of people. These people are the Kool Kidz who have picked up Ruby on Rails over a weekend, created a blog in 15 minutes, sneaked a Ruby script onto their company’s servers, and are so delighted with their new toy that they think it should be the basis of the multi-million pound invoicing system currently wanted by the Accounts Department, which they’d quite like to build if they can use Ruby but which they have no intention of sticking around and supporting for the next ten years.

Unfortunately my personal answer to these people contains too many expletives to be included on a family blog.

Just as well we’ve got some other answers, then…

2. Confidence

Ruby might be a terrific language, with good support, and it might be really reliable. But the redesign work that’s going on now produced its first public release in November 2006. So the work will have started a few months before then, and the planning a while before that. Let’s round it out to January 2006, two years ago from now.

Casting your mind back two years you may recall that Ruby was an up-and-coming language, but it hadn’t really been proven running large scale websites. Sure, 37signals were working with it to great effect, but that’s only one case study, and not of a typical company. If you’re going to sink someone else’s money (that is, your employer’s money) into a big project you have a responsibility to ensure you’ll get results. You’ll want to be sure there is sufficient expertise in the marketplace to call in help when you need it, you’ll need to see several other similar projects that have succeeded with it, and you’ll probably want to know of a few projects that have failed with it so you know what not to do. With the state of Ruby at the time there just wasn’t that weight of evidence that supported its use for our purpose.

3. Scalability and socialness

Finally, a very important factor in our consideration was a kind of scalability, and what one of our architects calls socialness. It’s the scaling of the team.

There’s a world of difference between four-or-so developers writing some software and several dozen developers writing it. The day-to-day mechanics of writing software changes significantly when you’ve got so many developers that…

• there are too many to fit round the same table;
• you can no longer rely on saying something aloud and being heard by everyone;
• you couldn’t possibly have recruited them all if you had wanted Indentikit developers who would all naturally solve all problems in exactly the same way;
• any code you write is likely to be picked up next by someone you’ve not happened to speak to for more than a fortnight;
• any code you pick up is likely to have been written by someone you’ve not happened to speak to for more than a fortnight;
• it’s only to be expected that the people you end the project with won’t be all the same people you started with.

When all this is the case, then code consistency becomes hugely significant, and just relying on people’s own technical and communication skills isn’t going to be sufficient — you need your software to keep you on the straight and narrow. We weren’t comfortable that a language with the fluidity and flexibility of Ruby would provide that.

Postscript

I’ve just made a quick calculation: If quality is compound, and you’ve got 25 developers who each manage to code to 95% of your desired standards, then the quality of your codebase becomes 0.95^25, or 28%. Okay, it’s a pretty spurious calculation, but it goes to illustrate the point that quality is more fragile across a larger team.

In the end, the “why not Ruby” question comes down significantly to historical reasons and human reasons.

And what would we choose if we had to make the decision today? Well, we don’t have to.

I was surprised to see Ken Schwaber talking about burn-down charts, as burn-up charts provide more information and are — for me — the preferred option. So this is a short article about burn-up charts and burn-down charts, both great tools for measuring progress.

First, though, a hat-tip to Ian Carroll, a colleague at MEN Media. His blog shows off the video I saw. In it, Ken explains Scrum and answers a few questions from Google employees. It was worth an hour of my time just for his explanation of the wider consequences of dropping quality. The argument may be familiar to you, but the clarity of the explanation and the use of the visual aid (a burn-down chart) is terrific. If you want to see just that then jump to minute 40.

Burn-down charts

A burn-down chart tracks how much work remains on your project and whether you’ll hit your deadline. The vertical axis measures work remaining. The horizontal axis marks your iterations, and you should mark which iteration is your target end date for the project. After each iteration you mark your progress on the chart and you can project forward to see whether or not you’ll hit your target end date.

In the diagram above we’ve gone four iterations, and the dotted line (the projection) suggests we’ve fallen quite badly behind schedule. After the first iteration you can see we were making good progress, but things changed in the second iteration and alarm bells should have sounded. The project manager should have started doing something then.

Burn-up charts

A burn-up chart tracks how much work is done. But it shows more information than a burn-down chart because it also has a line showing how much work is in the project as whole (the scope as workload), and this can change. On the burn-down chart it is harder to show a changing goal.

In the diagram the bottom line is the work done and the top line is the total scope. Dotted lines show projections. We can see that the scope remained steady for the first few iterations, and we would have expected to make the deadline. But scope increased around the fifth iteration. Even this wouldn’t have been too bad if that had been the end of it, but it continued to increase after that. The projections show that we won’t make the target deadline at our current rate of scope creep. In fact we probably won’t even make it if the scope remains steady.

Getting advanced

More sophisticated burn-up charts can show several scope lines, one for each release milestone. This way the team and the stakeholders can see the effects of, say, moving scope from one release to another.

Burn-down charts have the advantage that they’re simpler — they only show one line. Perhaps that’s why Ken used them in the video; much more would have distracted from his messages. But if you can stand a little complexity then I’d recommend burn-up charts as the more useful option for real-world situations.