Introducing Tool tax

I’ve been trying out a few different “tools” just too see what tooling looks like in different environments. There are several different tools solving the same problem in their own more or less unique way. They also take different amounts of time to solve the problem.

The time it takes to use a tool is a tax on the developers time. For example, there is a difference between doing a check-in in a source-control system when it takes 2 seconds compared to 0,2 seconds.

In money these figures are too small to measure: with an estimate of 10 check-ins per day you get 100 seconds per week compared to 10 seconds. It is a minor amount of time to optimize around when looking at the whole development process, but it matters much for the work environment. Switching to faster development tools can increase productivity not only due to the time saved when using them, but also due to reduced amount of content-switching.

I joined a session at DynCon 2011 where we did wolf pack programming. It was very interesting because it introduced an environment where there was no tool tax while developing. The IDE automatically updates and shares the code as soon as it can compile what you just typed in the IDE. Since Smalltalk can hot swap code the immediately updated the running production code. In essence there were no cost for committing, compiling, running builds, deploying and what not.

It turns out that behavior change. Collaboration becomes much more important as the system has zero cost for developing in a shared environment. After a few hours of wolf pack programming, the team was discussing lively and producing code collaboratively in a way that I’ve rarely experienced in real environments.