Thus, a metric in isolation will not help you reach your goal. On the other hand, assigning too much meaning to a metric leads to a different pitfall.

Treating the metric. Making alterations just to improve the value of a metric. Recognized when changes made to the software are purely cosmetic. Can be solved by determining the root cause of the value of a metric.

The most common pitfall is making changes to a system just to improve the value of a metric, instead of trying to reach a particular goal. At this point, the value of the metric has become a goal in itself, instead of a means of reaching a larger goal. This situation leads to refactorings that simply “please the metric,” which is a waste of precious resources. You know this has happened when, for example, one developer explains to another developer that a refactoring needs to be done because “the duplication percentage is too high,” instead of explaining that multiple copies of a piece of code can cause problems for maintaining the code later on. It is never a problem that the value of a metric is too high or too low: the fact this value is not in line with your goal should be the reason to perform a refactoring.

Consider a project in which the number of parameters for methods is high compared with a benchmark. When a method has a relatively large number of parameters (for example, more than seven) it can indicate that this method is implementing different functionalities. Splitting the method into smaller methods would make it easier to understand each function separately.

A second problem that could be surfacing through this metric is the lack of a grouping of related data objects. For example, consider a method that takes as parameters a Date object called startDate and another called end-Date. The names suggest that these two parameters together form a DatePeriod object in which startDate will need to be before end Date. When multiple methods take these two parameters as input, introducing such a DatePeriod object to make this explicit in the model could be beneficial, reducing both future maintenance effort, as well as the number of parameters being passed to methods.

the most common
pitfall is making
changes to
a system just
to improve
the value
of a metric,
instead of trying
to reach
a particular goal.

Sometimes, however, parameters are, for example, moved to the fields of the surrounding class or replaced by a map in which a (String,Object) pair represents the different parameters. Although both strategies reduce the number of parameters inside methods, it is clear that if the goal is to improve readability and reduce future maintenance effort, then these solutions are not helping. It could be that this type of refactoring is done because the developers simply do not understand the goal and thus are treating the symptoms. There are also situations, however, in which these non-goal-ori-ented refactorings are done to game the system. In both situations it is important to make the developers aware of the underlying goals to ensure that effort is spent wisely.

Thus a metric should never be used as-is, but it should be placed inside a context that enables a meaningful comparison. Additionally, the relationship between the metric and desired property of your goal should be clear; this enables you to use the metric to schedule specific actions that will help reach your goal. Make sure the scheduled actions are targeted toward reaching the underlying goal instead of only improving the value of the metric.

how many metrics Do You need?

Each metric provides a specific viewpoint of your system. Therefore, combining multiple metrics leads to a balanced overview of the current state of your system. The number of metrics to be used leads to two pitfalls, we start with using only a single metric.

One-track metric. Focusing on only a single metric. Recognized by seeing only one (or just a few) metrics on display. Can be solved by adding metrics relevant to the goal.

Using only a single software metric to measure whether you are on track toward your goal reduces that goal to a single dimension (that is, the metric that is currently being measured). A goal is never one dimensional, however. Software projects experience constant trade-offs between delivering desired functionality and nonfunctional requirements such as security, performance, scalability, and main-tainability. Therefore, multiple met-