Those who opposes metrics argue that software metrics can only be used to indirectly help a team build better products, as measurements of a product is not measurements of real market success. But so is almost everything else in product development. Software architecture is generally viewed as an important activity, although architecture is mostly about patterns and choices, what tools and frameworks to use to solve a particular problem, either this concerns programming languages, frameworks or cloud strategies. Every pattern has advantages and drawbacks, no solution has all the benefits. And software architecture has virtually no bearing on commercial success, except for the fact that main stream solutions are relatively safe to use, especially on a fickle market.

For other industries, metrics have been a way to communicate about a product. Measurements reveal key characteristics of their products, which for an experienced engineer translates into certainties and risks that may need a response. The software industry got off on a wrong foot from the start when it measured source lines of code, also known as SLOC. SLOC may give a hint on complexity, effort and productivity, but it is now regarded as a blunt and largely obsolete tool by most.

The most appropriate way to use metrics in software engineering is to make measurements in both the problem domain and in the solution domain. The problem domain is handled by requirements metrics, while the solution domain is all about tangible product characteristics, such as start-up time, memory footprint and leeks, execution bottle necks, failures and other metrics that may seriously affect user experience. Requirements metrics is a whole different ballgame, as it uses weighted and unweighted measurements to calculate the quality and information content of the product requirements. Requirements can have a high information content and low quality, but they seldom have high quality and moderate to high information content at the same time. Requirements metrics can easily be tied to other, high level goals that concern product quality and content, or to scheduled deliveries in the project. The purpose of requirements metrics is to basically produce a Requirements specification of high quality. If there are no requirements in the project, the quality is unknown and risks are 100%.

There is no known method to measure usefulness or commercial success of a product. These kind of characteristics are controlled by creativity, talent, experience and a bunch of other parameters that can’t be easily quantified or measured in a project, although people try constantly to do so. The best way to measure these types of characteristics is to hire people with a proven track record, although the risk of building a dud is still significant.

By measuring ambiguity and clarity of the requirements, the conjecture is that issues that would otherwise be hidden in the problem domain are revealed and addressed effectively at an early stage. There are still issues that can’t be addressed through metrics, such as technology risks, but these issues have a tendency to hide behind requirements that are poorly specified. To most projects, this means that the issues are not found until the product is tested at full scale, which leaves product development to be an exercise in trial and error.