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.