You can read his latest post here, go ahead, I'll wait.
http://www.joelonsoftware.com/items/2006/11/10b.html
While Joel is absolutely right about his observations on bad metrics, not having any metrics at all is just as sinful. Yes, you can have metrics in development/knowledge worker positions. Yes, crafting them is more difficult than in a factory situation where you can just count the number of widgets worker x produces. Yes, if you don't match metrics to organizational goals you can get workers abusing them and actually hurting the company instead of helping (number of lines of code anyone?).
This is why you need good management in place that can balance the organizational goals of the company with the motivations of developers. As far as I'm concerned, in a development project you normally have 4 major categories to develop metrics around. They encompass long term and short term goals:
Short Term Goals | Long Term Goals |
Initial Development Cost | Maintainability |
Timeliness | Effectiveness |
When you look at this grid, it should make a lot of sense to you as a developer. Your end users want software delivered on time and management wants it delivered at as low as cost as possible. In the long term, you realize that maintenance is costs are about 9:1 over initial development costs so you want the application to be maintainable. Everyone wants the software to be effective, increasing productivity and helping the business.
The reason I choose this grid is simple. What do you do when cost/time starts over-running? You cut features (lowering effectiveness) or cut out aggressive logging, strong code reviews, testing time, etc (Maintainability). On the other side, maximizing effectiveness and maintainability takes time and money.
The point to be gained from this is that every organization has its own weight for which of these metrics are most important on a given project. Is it a temporary bandaid/throwaway project? Then timeliness and cost will trump maintenance and effectiveness. If it's a critical business system that will be used for years to come, the weighting will shift more towards effectiveness and low maintenance costs.
This is ultimately where you metrics come in for your developer team. You can build metrics for timeliness and cost (hitting deadlines, milestones, accurate estimations) and you can also build metrics for effectiveness and maintenance (bug tracking, change management, end user productivity, etc). Joel is right in that there's no single bullet proof set of metrics out there, because companies have different needs and goals. You can develop metrics that make sense to your organization.
Just keep in mind that measuring only developers is a recipe for failure. IT in an organization is a supporting process that is designed to increase profitability through maximizing the effectiveness of the principal users at the lowest cost possible. Measuring that effectiveness and ongoing costs is the best way to evaluate whether your IT staff is performing as well as it should be.
Print
posted @ Monday, November 13, 2006 1:51 PM