After almost 5 years, I find myself no longer working for ThoughtWorks. Moving on was a hard decision but it was time for a change. I’m looking forward to my new job, but I’ll miss being ‘’.

I won’t miss Lotus Notes.

The Next Language for Startups?

Nobody who can spell HTML would be surprised if you launched a Web 2.0 company and chose to use Rails to build your site. On the other hand, one of the ways startups beat the competition is by taking the road less travelled, by using a language considered wierd or niche by everyone else. Success can lead to the language being noticed and becoming more widely accepted.

I was pleased to discover that Slideaware have migrated from Rails to Erlang for their online powerpoint collaboration application. Not because I don’t like Rails, but because I really like Erlang.


It’s not friendly and it makes it really hard to pay for stuff.

Has anyone ever actually had a smooth user experience with Paypal? Every single time I’ve tried to use it I’ve had problems.

The new credit card loop of death. A particular favourite. This is where paypal keeps insisting that ‘this card has already been registered’ while steadfastly refusing to let me actually use it to pay for stuff, eventually looping back to the ‘add card’ screen for another fun go around.

Amnesia. Several times paypal has let me go all the way through adding a new card, accepted it and then just forgotten all about it, forcing me to add the card again. Often leads to another free trip to the loop of death above.

Insisting that a payment has already been made (for an item on ebay) and refusing to let me continue, despite ebay having precisely the opposite opinion. Makes the whole cute ‘an ebay company’ logo look like some kind of ironic joke.

Workflow bugs in little-used ancillary features are one thing but… this is paypal. One might consider the workflow around, you know, ‘paying for stuff’ to be something of a core function?

Mistakes you will make in software

Almost without fail I see certain errors repeated on every single software project I come across. The projects that successfully dodge these pitfalls almost always do so because someone on the team fell into them once before and swore they wouldn’t do so again. Those of you who haven’t yet been burned by this class of error will almost certainly protest about complexity or wierd design choices in the code made by those who have.

Who are these heinous kingpins of crime in the bug ghettos of the software world? Its a work in progress, but the initial contenders are:

  • Dates and times
  • Money
  • Concatenated strings as identifiers

Those of you who’ve been beset in the past are nodding right now, those who haven’t are probably saying, “they don’t seem very complicated.”

Which is exactly why they’ll get you sooner or later. Then you’ll remember this post, and you’ll nod.

Feed me

It’s been kindly pointed out that my feeds and half my category links are broken and have been for a while. Probably nobody is left who still actually uses a browser to read blogs, but, as this dovetails rather precisely with my assumptions about readership size; and faffing with moveable type templates rates somewhat lower than not, it may take a while before it all gets sorted. Apologies to anyone who’s still committed enough to make the effort, I’ll try and get round to sorting it.

Tiny Types

There’s a pattern I’ve used with great success a couple of times now that tends to provoke strong reactions in developers when they first see it. I’ve had comments along the lines of “that’s horrible!”, “ugh” and “that’s way too much work”. The pattern is this: the encapsulation of simple built-in types within domain specific classes. Sounds simple and it is.

Lets take a concrete example:

public class Customer {
private final String firstName;
private final String familyName;
private final int ageInYears;
private final int heightInCentimetres;

public Customer(String firstName, String familyName, int ageInYears, int heightInCentimetres) {
this.firstName = firstName;
this.familyName = familyName;
this.ageInYears = ageInYears;
this.heightInCentimetres = heightInCentimetres;

Fairly standard stuff. But note the constructor signature: string, string, int, int. Not really very expressive and exceedingly easy to get the parameters out of order. But who would get someone’s first and last names mixed up? Ask any Chinese person how often that happens. They place their family name before their given name. Also, strings and integers are not usually domain concepts unless you are writing a compiler. Someone’s first name is not interchangeable with their last name the way two strings are. So how about this:

public class Customer {
private final FirstName firstName;
private final FamilyName familyName;
private final Age age;
private final Height height;

public Customer(FirstName firstName, FamilyName familyName, Age age, Height height) {
this.familyName = familyName;
this.firstName = firstName;
this.age = age;
this.height = height;

It is at this point that most developers recoil. No way do I have time to add an entire class just to wrap a string! Or two entire classes in this case! Actually, it’s four new classes. All of which I wrote while writing this post. There is a reasonable amount of boilerplate. Including toString, equals, hashCode and a getter makes for about 40 lines per tiny type, almost all of which can be condensed into an IDEA template. And most systems have a finite number of domain concepts so the rate of adding these tiny types isn’t very high and drops off fairly quickly.

But why do this? I consider it playing to the strengths of a statically typed language. Java will never be as Ruby as Ruby, but it can be much more Java than Ruby ever will. All sorts of useful things start to happen when the library types and primitives have been banished from your api. Now the compiler can spot transposition errors. Equals and hashCode can be implemented with domain specific semantics. It’s much harder to accidentally pass dollars into a method that was expecting pounds sterling (but actually took a double so it could have been anything). Readability is greatly improved. Automated refactoring, code completion and code navigation all gain a new level of power. ‘Find usages’ on the FirstName class produces far more useful results than doing it on the String class.

You probably still don’t fully believe me if you haven’t tried it, but this is one of those times where cognitive dissonance has got it wrong. It really is an exceedingly useful approach.

Happy 2007

The sounds of New Years in London: 10 minutes of fireworks, followed by several hours of sirens. Have a safe celebration everyone.

Tools Matter

During a recent discussion with some colleagues about which technology to choose for a project I mentioned the importance of tool support, particularly around the IDE. I found myself surprised by the wide range of opinions about the importance of tools. Not about the specifics of whether IDEA was better than Eclipse or VS2005 with Resharper, but about how much importance should be given to tool consideration when choosing a development technology.

Let’s say the team has free reign about language choice and has narrowed the decision to Java or Ruby. Both languages are known to the majority of the team. At this point, for a modern project process (lightweight / agile) I would factor in the team size and strongly advocate Java if the team had more than about 3 to 4 developers, justified purely by the superior team support capabilities of IntelliJ IDEA and Eclipse. By which I mean their code exploration and refactoring capabilities.

This is where the arguments start. Er. This is where this particular argument starts.

A typical response might be, “as an experienced developer, while I find automated refactorings useful, I don’t need them and certainly wouldn’t let my technology decision be swayed by whether a flashy IDE exists. That’s just laziness. Developers were refactoring by hand years before refactoring IDEs existed. The improved productivity and less lines of code required with Ruby outweighs any time saved from a few keyboard shortcuts.”

This isn’t a bad counter-argument. For an individual developer working alone.

With sole access to a codebase that I wrote entirely myself, I’d generally agree. I might disagree with the implication that the time saved by the keyboard shortcuts isn’t that significant. I’d love to see a study done where a team had to refactor a codebase and add a feature with a modern IDE compared to another team doing the same thing with Emacs. Moving on – the point that this response misses is that there is a team working on the code not just one developer. I believe the value of automated code modification and exploration increases as a function of team size.

Why should this be? With increasing team size there is an increase in communication overhead and achieving a shared understanding becomes harder and takes longer. Each new member added to a team has an exponential effect on the number of lines of communication.

What does this mean? It becomes increasingly likely that decisions and assumptions made in the early stages will be found to be sub-optimal as the project progresses and the team learns. Code won’t be in quite the right shape or quite the right place. The domain model will need to evolve and change. A larger team implies a larger system and therefore more code. It will become very unlikely that everyone in the team knows where everything in the code is. Duplication can creep in. For all these reasons a larger team will necessarily need to explore and change the code as the project progresses. Without automated support even changing a method name for improved understanding becomes a fraught task. In a dynamic language automated support is even more important as there is no compile stage to tell you if you forgot to change one of the callsites. With sufficient test coverage this risk is reduced but never eliminated. So what will generally happen is that changes that should be made aren’t made as the effort is too high.

Humans build tools. It’s one of our most defining characteristics. We build tools to magnify our physical strength and our mental faculties. There’s a reason flint axes have been replaced by chainsaws. We should never underestimate the importance of good tools to achieving productivity.

Short Lens on London

What could follow a day with a 135mm telephoto? A day with a 12-24mm wideangle! Another day spent with a lens I don’t use often enough. I though it would be interesting to walk the same route I did before.

Some quite different shots came out, partly because I got a lot more creative in Lightroom afterwards (which itself was a result of trying to salvage a bunch of truly mediocre shots). But also because you have to work really hard to fill a wide angle lens with interest. The number of times I walked to the ‘right’ spot while looking through the viewfinder and took the camera away to find myself mere inches from smacking right into the object I was focussing on…

Long Lens on London

Many years ago, when I was young (okay, 2004) and foolish (that’s still true), I bought a Nikon 135mm f/2 ‘defocus control’ lens, ostensibly to photograph a wedding.

That didn’t work out, but I’d paid for the lens and it was languishing in my camera bag, so, having just upgraded my camera to a D200 I resolved to get out and try using this superb lens.

Here’s what I came up with one sunny november day.

I love: the perspective compression (St Paul’s looks huge in some of the shots!), the narrow depth of field.
I don’t love: the evil purple fringes of doom on some of the high contrast shots at f/2.

Top tips: pick a day with good light. Hand holding this lens needs shutter speeds in excess of 1/200 or faster for my shaky mitts. Alternatively get creative about finding places to lean against or rest the camera on. Both the D200 body and the 135DC lens are made of metal, so we’re talking some serious tonnage when you put them together.

All the indoor shots at the Tate Modern were taken either resting the camera on a railing or the donation bucket, coupled with holding up the lens ‘snooker cue’ style while trying to get down low enough to see though the viewfinder. Expect funny looks while attempting this.