Article development led by
Four common pitfalls in using software
metrics for project management.
BY eRiC Bou WeRs, Joost VisseR, anD aRie Van DeuRsen
Are sof TwAre Me TriCs helpful tools or a waste of time?
For every developer who treasures these
mathematical abstractions of software systems
there is a developer who thinks software metrics are
invented just to keep project managers busy. Software
metrics can be very powerful tools that help achieve
your goals but it is important to use them correctly, as
they also have the power to demotivate project teams
and steer development in the wrong direction.
For the past 11 years, the Software Improvement
Group has advised hundreds of organizations
concerning software development and risk
management on the basis of software metrics.
We have used software metrics in more than 200
investigations in which we examined a single snapshot
of a system. Additionally, we use software metrics to
track the ongoing development effort of more than
400 systems. While executing these projects, we have
learned some pitfalls to avoid when using software
metrics in a project management setting. This
article addresses the four most important of these:
˲ Metric in a bubble;
˲ Treating the metric;
˲ One-track metric; and
˲ Metrics galore.
Knowing about these pitfalls will
help you recognize them and, hopefully, avoid them, which ultimately leads
to making your project successful. As
a software engineer, your knowledge
of these pitfalls helps you understand
why project managers want to use software metrics and helps you assist the
managers when they are applying metrics in an inefficient manner. As an
outside consultant, you need to take
the pitfalls into account when presenting advice and proposing actions.
Finally, if you are doing research in
the area of software metrics, knowing
these pitfalls will help place your new
metric in the right context when presenting it to practitioners. Before diving into the pitfalls, let’s look at why
software metrics can be considered a
software metrics steer People
“You get what you measure.” This
phrase definitely applies to software
project teams. No matter what you define as a metric, as soon as it is used to
evaluate a team, the value of the metric
moves toward the desired value. Thus,
to reach a particular goal, you can continuously measure properties of the
desired goal and plot these measurements in a place visible to the team.
Ideally, the desired goal is plotted
alongside the current measurement to
indicate the distance to the goal.
Imagine a project in which the runtime performance of a particular use
case is of critical importance. In this
case it helps to create a test in which
the execution time of the use case is
measured daily. By plotting this daily
data point against the desired value,
and making sure the team sees this
measurement, it becomes clear to every one whether the desired target is
being met or whether the development
actions of yesterday are leading the
team away from the goal.