A log of articles I found for later reading. ...................................................... ..............................Not necessarily my point of view though.

Monday, January 5, 2009

The Productivity stack is not about productivity

All the tools, widgets and gadgets that fit into the Productivity Stack are not really productivity tools as might be understood at face value, but rather quality and flow improvement tools.
Have you ever asked why, despite there being more and more productivity tools all the time, many of which even you adopt there is not a noticeable industry improvement in productivity. At face value this appear to simply be the manifestation of Brooks no silver bullet ( which I fully support ), except in this case there is one interesting conundrum, ask anyone who uses these tools, and they will tell you that they cannot work without them anymore! They actually work
So what is going on.
Well as I see it, it is simply that there are 2 views on the word productivity.
Your Project Manager will tell you that if you increase productivity then the project will come in earlier, ( but then again, despite knowing better, and being told repeatedly, they tend to also believe that adding more people to a project will also make it go faster – at least these days the expectation is not linear ).
If however you ask a developer, if they were allowed to use a decent IDE with all the good refactoring and source browsing tools / plugins, is that going to make the project come in any earlier, and they will reluctantly tell you no ( at least not significantly ) , but feel dirty because they know that the tools are definitely helping their productivity.
You see the PM views the world from a high level project perspective, and the developer from a line by line perspective.
What is clear by looking at the classic LOC measurement ( albeit it dodgy ) is that the average developer does not spend a lot of time writing code, in fact we write very little code. We spend most of our time thinking, understanding, explaining but mostly managing all the interruptions that stop us doing those!
So when we do get around to writing code, anything that stops the interruptions of our flow increases our productivity of development. So while we are improving productivity it is only an optimization on a small part of the project time.
However, what is not obvious is how huge that improvement is on Quality.
Good productivity tools allow the developer to concentrate on the problem at hand and not on using the tool. It tortures me to see people have a thought, which means they need to a open a file to explore the idea, and then see them slowly launch the explorer window and painfully click through each folder until they find the file, by which time their thought process has been swopped from the problem they are working on to the issue of “now where is that file again?”, then they have to context switch back into why they were looking for the file in the first place. What is worse, is they don’t even know they are paying this huge time price!
In short the productivity tools, contrary to popular belief, dont meaningfully speed up development time, and even if they did, that is not their real value. Their real value lies in the fact that in the everyday activity of coding ( I am talking at the minute by minute level ), these tools stop the break in flow that happens even when you are not being interrupted by other people, and allows you to work closer to the pace that you think at.
This continued flow in the end leads to better quality, not faster development.

For me the Key Productivity Stack for Developers would be something like this :

* Learn your keyboard shortcuts
* Learn to type ( link to Coding Horror blog by Jeff Atwood )
* Use a decent source browser ( VSK is mine for Visual Studio )
* Use a decent editor

via http://www.blog.stackingit.com/2008/11/productivity-stack-is-not-about.html