Determining the overall productivity of a dentist’s office
is easy. All you have to do is look as far as the number of patients, their wait time, and their retention rate, before a picture starts to emerge.
With an IT team, it’s a bit more complicated. You can’t just look at the number of hours a team puts into a project, the number of projects they’re working on, and the number of projects completed. When analyzing the effectiveness of the software engineering process, one needs to consider how things such as code coverage, coupling, and balanced scorecards affect project completeness. This sort of analysis can only be done when an IT manager sets up software metrics.
What are software metrics?
The name is self-explanatory; software metrics measure the software development process. These metrics can be measured directly, such as with the number of bugs per line, or measured indirectly, such as with the DSQI. While most people assume that software metrics are used only to determine line count , and thereby the productivity of programmers, this isn’t the case. Software metrics, most importantly, allow IT managers to meet their project goals.
Common Software Measurements
- Bugs per line of code
- Code coverage
- Cohesion
- Coupling
- Instruction path length
- Number of classes
- Number of interfaces
- Number of lines of code
- Number of comments per given section
- Program size
- Time needed to execute the program
- Time needed to load the program
Deciding which metrics to use
Calculating the numbers isn’t difficult. The most challenging part of software metrics is determining which numbers are most useful to the company. Performing the Goal-Question-Metric (GQM) technique allows you to determine this.
The first step in the GQM technique is to think about your company goals. What do you want to do? Make these goals as quantifiable as you can. For example, a goal of yours might be, “Increase test coverage to 70% for any file that is modified.”
Once you have your goal set in stone, you can move onto the second step, questions. Here, you must think of a question that, when answered, would tell you whether or not you are reaching your goal
. One such question might be, “How many files do we modify in a month?” Another question might be “How often do we test files after they have been modified?”
Once you have your goals and questions in place, you must determine which metrics you will use. A good metric starting place is with numbers that give you information as to the time spent, cost, size and quality of a certain software development process. These analytics are:
– Duration of projects, both estimated and real
– Time spent on different parts of the project
– Labor hours, both estimated and real
– Product size (lines of code)
– Defects (number of bugs in the lines of code)
These numbers help you establish a baseline. However, in addition to this, you need to have metrics that answer your questions. In the case of our example question, one set of metrics might be the number of files modified in a month. Make sure that you decide which metrics you want to use in the beginning of the project, so that you can establish a baseline. Without this baseline, you won’t know if you’re actually improving your work output or not.
Contention
Software metrics are often fought against for two reasons. Firstly, many developers feel that the metrics will only be used to monitor their productivity, and that they will be punished if their rate doesn’t stand up to the industry output norms. This isn’t why companies use metrics though, so confronting this misconception is easy. All IT managers need to do is explain how the numbers will be used and how they will NOT produce a rewards system. One developer may be writing 500 lines of code in a day, but his task may be easier than that of the developer writing 10 lines in the same time period. A rewards system based off of these numbers has the potential to skew the rewards towards people performing simpler tasks. As a result, a rewards system should not be based off of software metrics. An IT manager must keep this in mind, as well as make sure that their developers see the numbers, and how they’re using them to determine goals.
Others fear that developers alter their actions in light of software metrics in order to meet goals. For example, if the goal is to increase the lines of code within a certain time period, critics fear that developers will then start writing code more quickly, but with many defects. This is not a problem if analytics are balanced between the time spent, cost, size and quality of a software development process. With balanced metrics, this increased defect rate will be noticed along with the increased size. Analyzing a broad range of balanced analytics prevents developers from trying to “cheat” the system.
Using software metrics allows an IT manager to meet their goals. You see, once a baseline is established, they’ll be able to make realistic goals and track their progress. They’ll only be able to work towards their goals though if they pick the right analytics. Making sure that the analytics are balanced between the time spent, cost, size and quality of a software development process ensures that IT projects run both on time and on budget.
How do you determine which metrics will allow you to reach your goals? Let us know in the comments section below, or join the conversation on Facebook, Twitter, or LinkedIn.
Looking for more information like this? Check out other blog posts on this topic by clicking on the buttons below:
Thanks to jeferonix and konradfoerstner for the use of their respective photographs.
