2 comments
Various 
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:
2 comments
IMHO there are two dimensions missing in your pictures. You could have a great tool but in the hands of a fool it would have to be an awsome tool to protect you from the fool. Two, you might have a great tool but when used at the wrong time or improperly used it might give you a false feeling of greatness. (Forgetting to label your builds in Source Safe or reverse enginering class diagrams and pretending you now have your documentation covered) (No, I am not implying Source Safe is a great tool 😉 ) See: http://www.google.com/search?q=fool+with+a+tool
Erno de Weerd
Great points Erno! I fully agree with that: you still need to know your craft, no matter how good the tool is (a great hammer does not make a great carpenter), and you need to know the tool to effectively use it. I’ll try to update this in the picture tonight using some advanced imaging tool (paint.net).
peterhe