Productive Developers

In an interesting entry over at agile focus, they mention the developer productivity question. They also discuss why defining developer productivity is such a hard thing to do. The question of whether or not productivity can or cannot be accurately measured is still unanswered as far as I'm concerned.

Developers have a goal to reach on any given project that they happen to be working on at any given time. Or, at least they should have a goal. If they don't have an overall idea of what exactly it is that they are building, then there are bigger problems elsewhere and the company need not concern itself with measuring developer productivity. As stated in the entry, if the developer does have a goal to reach, any forward motion made toward that goal can be considered progress. Again, nearly impossible to measure.

This of course begs the question, should developer productivity even be measured at all? Or should management be able to answer yes or no to the question of whether or not a developer is productive? That is, making progress vs. not making progress. I think this is a valid approach to measuring developer productivity if measurements are taken relative to the expected skill of the developer.

Agile software development

The Hitchhikers Guide to Software has an interesting post on "why the waterfall model does not work". I think he basically nailed the reasons why the waterfall approach to software development does not work. The main reason it fails is the huge amount of optimistic assumption required. There are simply too many variables associated with software development.

What makes agile software development superior to the waterfall approach? I think the name of the methodology speaks for itself. It allows developers to move ahead in the project quickly and easily. Also, as goes without saying, early feedback is invaluable to a software development team.