What are the most useful software development metrics? [closed]

Answer 1

improve my team’s software development process

It is important to understand that metrics can do nothing to improve your team’s software development process. All they can be used for is measuring how well you are advancing toward improving your development process in regards to the particular metric you are using. Perhaps I am quibbling over semantics but the way you are expressing it is why most developers hate it. It sounds like you are trying to use metrics to drive a result instead of using metrics to measure the result.

To put it another way, would you rather have 100% code coverage and lousy unit tests or fantastic unit tests and < 80% coverage?

Your answer should be the latter. You could even want the perfect world and have both but you better focus on the unit tests first and let the coverage get there when it does.

Answer 2

Code coverage percentage

Answer 3

Velocity: the number of features per given unit time.

Up to you to determine how you define features, but they should be roughly the same order of magnitude otherwise velocity is less useful. For instance, you may classify your features by stories or use cases. These should be broken down so that they are all roughly the same size. Every iteration, figure out how many stories (use-cases) got implemented (completed). The average number of features/iteration is your velocity. Once you know your velocity based on your feature unit you can use it to help estimate how long it will take to complete new projects based on their features.

[EDIT] Alternatively, you can assign a weight like function points or story points to each story as a measure of complexity, then add up the points for each completed feature and compute velocity in points/iteration.

Answer 4

Track whether a piece of source has undergone review and, if so, what type. And later, track the number of bugs found in reviewed vs. unreviewed code.

This will allow you to determine how effectively your code review process(es) are operating in terms of bugs found.

Answer 5

Perhaps you can test CodeHealer

CodeHealer performs an in-depth analysis of source code, looking for problems in the following areas:

• Audits Quality control rules such as unused or unreachable code, use of directive names and keywords as identifiers, identifiers hiding others of the same name at a higher scope, and more.
• Checks Potential errors such as uninitialised or unreferenced identifiers, dangerous type casting, automatic type conversions, undefined function return values, unused assigned values, and more.
• Metrics Quantification of code properties such as cyclomatic complexity, coupling between objects (Data Abstraction Coupling), comment ratio, number of classes, lines of code, and more.

Answer 6

Inverse code coverage

Get a percentage of code not executed during a test. This is similiar to what Shafa mentioned, but the usage is different. If a line of code is ran during testing then we know it might be tested. But if a line of code has not been ran then we know for sure that is has not been tested. Targeting these areas for unit testing will improve quality and takes less time than auditing the code that has been covered. Ideally you can do both, but that never seams to happen.