Why tools matter
Improving software development productivity is a much discussed topic, with many different schools of thought. Some will say you need to get people who can “Hit the High Notes“, others will focus on teamwork dynamics as a means to ultimate productivity, while some will emphasize that using the best tool out there is critical. A lot of these camps will often downplay the others, stating that their focus on productivity is the only one that really matters.
I think all aspects matter a lot, and depending on the situation, you should focus on different aspects. Small teams vs big teams vs novice teams vs experienced vs long vs short projects, etc. The important thing to recognize is the relations between them and how they compound or conflict with each other.
Tools play an important role here (with tools, I mean “automated” support, such as an IDE, build tool, version control, etc.). In my opinion, tools can determine the bandwidth of operational productivity. In other words, tooling will play a role in determining the barrier to entry to perform certain activities, and the maximum theoretical performance a team member can reach using the tool.
A nice example is creating a build. If properly tooled, everyone should be able to start an automated build with the press of a button (or even better, it just happens). Otherwise, creating a build may involve several complex steps, requiring specific knowledge and coordination, and is likely to be executed by a single team member as an “integrator” only. A properly automated build reduces the barrier to entry for the task of creating a build.
If a version control system does not support certain features (like atomic commit, for instance), or is very slow, this may limit the bandwidth of team members using the tool. Limited tool support incurs overhead in the form of error-prone behavior, complex workarounds, and increased waiting time.
Of course, tools are not the only potentially governing boundary factors for productivity. Just simple pen and paper are a great drawing tool, easy to use, very fast, and very mobile. On the other hand, it is difficult to navigate and search through paper drawings, or maintain them when something changes. Tools should always be viewed in the context of a given task and situation.
I tried to summarize this using this very sophisticated picture: