- Keep them lightweight - start light and see what happens. If you are getting interesting results, consider some deeper investigations into a particular area.
- Review and discard when appropriate - Metrics often have a shelf life - what was useful at one point in your development cycle or state of your development process can become irrelevant or not cost-effective later on. Some metrics are always useful, some have temporary value only.
- Make the tools do the work - dig metrics out of log files or by analyzing your repository rather than by forcing developers to enter extra keywords and fields. Ask yourself the question: "What are the minimum things developers need to do to get their work done?", and "What can we gather without extra input?" As Joel Spolsky puts it: "People add so many fields to their bug databases to capture everything they think might be important that entering a bug is like applying to Harvard. End result: people don't enter bugs, which is much, much worse than not capturing all that information."
- Finally - Don't abuse your metrics! Use them in a trustworthy and transparent way (see the previous. If you use metrics to punish (or reward) individuals, it can utterly kill collaboration & cooperation. People will will quickly learn to give you what you measure (as per the quote from Eliyahu Goldratt at the start of this article) and management will reward mercenary motion over palpable progress. If instead you collect and publish the metrics in a spirit of openness, collaboration, cooperation, and continuous improvement, they can add tremendous value!
We close by noting that some have described CM as the part of the software development process that is most like assembly-line manufacturing. It is in this vein that we offering the following quote:
"There are five golden metrics that really matter: total cost, total cycle time, delivery performance, quality and safety. All others are subordinate."
--from Manufacturing’s Five Golden Metrics