Look at any car’s dashboard today, and you will find the same set of core indicators. The primary element is always a speedometer, followed by a less prominent fuel gauge and odometer, after which the information tapers off quickly. There may be a temperature gauge or just a couple of ‘idiot lights’, there might be a tachometer, there may be tire pressure indicators, possibly a few others. While there is a trend these days to increase the information available to the driver (not unlike the trend of adding features to already bloated desktop applications), the important elements of a dashboard really haven’t changed for years.
This consistency over time is, literally, no accident. The driver’s primary goal behind the wheel is to safely navigate from Point A to Point B, and aside from the feedback provided by the windows and mirrors, the dashboard provides the information that allows the driver to reach that destination. Am I moving at a reasonable speed, do I have enough fuel, is the engine working within acceptable operating parameters? The rest is secondary.
What’s meaningful to measure in a car is all a matter of perspective. Take that same car to the mechanic for a tune-up, and he will only glance at the odometer to see whether it’s close to the time for a new timing belt or other scheduled maintenance. The key indicators for the mechanic today come from the on-board computer that provides detailed information about the engine’s timing, fuel mixture, and a host of other measures that don’t even make sense to most drivers.
What’s meaningful to measure in software development is also a matter of perspective. As with a car, there are literally thousands of things that could be measured on a software project, and it is important to avoid the temptation to measure for the wrong reasons:
- We want to avoid simply looking at the measures that are at our fingertips and easy to gather in order to distill useful information (“our timesheets are telling us that we’re all working 40 hour weeks…”),
- Avoid manipulating information to tell us what we want to hear (“since we have stopped looking for defects, our defect count has gone way down…”).
Dashboards for software projects, both commercial and home-grown applications, have been all the rage for the past few years – with all manner of information displayed. Rather than providing the useful information to appropriately drive the project, they often end up more like those activity centers that we place in our children’s playpens – they can serve to pacify senior management with all the charts and dials, but don’t do much else. Selecting appropriate measures is not that straightforward.
One person’s meaningful measures can be useless for someone else. A high Cyclomatic Complexity can raise alarms for an astute developer, while a low Schedule Performance Index might do the same for a project manager. Your perspective, consisting of the environment and culture you are working in, your role in the project, and whether you are focused on strategic or tactical issues will determine the goals you set. These in turn will help you ask the questions of the project to identify whether or not you are achieving these goals, and the questions will determine which are the most meaningful measures to take.
The GQM (Goals/Questions/Metrics) approach for building a metrics program, coined by Vic Basili, describes a disciplined approach to identifying measures that will be meaningful for your context. Done correctly, you will have a small handful of measures that make sense for you, and help you make the right decisions on your project. You will have the right dashboard to help you get to your destination with no accidents. – JB