| Meri William over at [Geek | Manager](http://blog.geekmanager.co.uk/) blogs about the common myth that business equals productivity: |
It’s really easy to mistake “busyness” for productivity. The folks always rushing around, having meetings and complaining about how busy they are certainly LOOK like they’re doing a lot. But the reality is that effort and output are not always related. Productivity is about getting loads done — how you spend your time should be up to you.
Coming in at 8:00 reading email, attending a few meetings while checking your CrackBerry a lot, going to lunch, then spending most of the afternoon writing documentation on software that’s already been completed and tested is very low productivity. Sure you’ve spent 8 hours working, but there’s very little to show for it except say for some very low value documentation that no one else is likely to ever read.
This happens all the time in large consulting projects. After the firm lands the work they go out and hire any contractors they can find on short notice. They dump them out on the client site and start billing 8 hours a day. Maybe the project actually does get done eventually, but generally it’s a few of the developers that do the bulk of the work. Many of the other junior contractors may actually be adding reverse productivity by injecting bugs as they produce line after line of cut and paste code. From a pure clock watching activity the lowest skilled developer on the project has probably put in more time than the most productive person.
The real problem is time is an easy metric to track, while productivity on a software project is difficult. Tracking hours billed or percentage done is easy. Tracking software quality or features completed requires more effort and certainly more technical knowledge. There’s plenty of false technical metrics that have been used from lines of code to the number of function points completed. Both of these measure how much typing you’ve done, but the best systems have as little code as possible necessary to implement the features that are actually used.
The best metric I can see with productivity is how many production quality features are getting done and how quickly. You can measure the ROI on something you can deploy at the end of any iteration, you can’t measure any ROI on the fact that you’re 80% done with the software design.