Software Metrics — The Rule of Control

by Krishna on July 1, 2007

Without measuring something, it is difficult to manage and improve it. When software is developed commercially, it has to manage several needs, including quality, time-to-market, production costs, etc. Many of these goals are set by the market place. For example, if only “x” people will pay for your software and you can only sell the software for a maximum of $y, then there is a limit on how much you can spend for creating it.

Many programmers, including skilled ones, instinctively object to any sort of metrics collection. One reason is that they feel that collecting metrics and preparing reports is an overhead and a distraction from their primary job of development. In their view, they are already doing the best job they can do. Any further improvements to the project could only be achieved by adding more resources, buying better tools and extending project deadlines to reduce pressure.

Having worked as a developer, I have some sympathy with such arguments. However, after managing other developers, I can also see the other side of the picture, which is that programmers can become very blind to their faults. Most developers have no real way of understanding how effective they are at their jobs and so they overestimate their capabilities. This is even more so true of programmers who rely on heroics to do development, debugging and bug fixing.

Let us consider the scenario of a programmer who just manages to meet his deadlines by working 12-hour days and weekends.

If you talk to such a programmer, he could object to metrics collection on many grounds. First of all, he is really hard-working and committed to the project. He also meets all his deadlines. He probably also writes good quality code and follows standards and best practices. He may be the person who volunteers for the really challenging tasks on the project. To spend time on metrics would be distracting and reduce his level of output, meaning he would be less efficient.

However, the situation also creates many problems. Foremost, this programmer’s way of working is not sustainable or replicable. The programmer would burn out within a few weeks and cannot sustain the same level of effort. Other developers may not be able to exert the same amount of effort. Therefore, you can only guess at how much time a similar task would take in the future. And this does not include any buffer time for unexpected technical difficulties. Finally, work done in such trying circumstances is likely to be buggy.

Metrics can actually expose the problems here. For example, asking the programmer to specify an estimate in hours and then comparing it with the hours he actually worked can very illuminating. You may think that the programmer already knows the number of hours he worked, but in my experience, they never do. A programmer may have spent 3 hours debugging a technical issue, but does not recall spending that much time.

Don’t think that you have solved the problem by obtaining this metric. Your work has just started. Confronting the developer with the discrepancy between estimated and actual hours opens up a new can of worms. Suddenly, you are given reasons about unanticipated technical issues or unrealistic deadlines, or even some philosophy that software development is intellectual work done by humans, not physical tasks on a machine at a manufacturing facility that can be estimated. Oy vey!

You can get into an argument with the developer, but arguments have a bad habit of never ending cleanly — the other person never really accepts your point. What you can do is actually try to accept what the developer is saying and give him control over the various issues that he is complaining about.

Ask the developer to give the deadline for a specific calendar day, assuming a proper 40-hour week and considering any holiday time. Ask the developer to put a buffer for technical difficulties. Ask the developer to add time for non-development activities, including documentation, meetings and metrics collection. Involve the developer in activities that could affect the development time. When the constraints and goals are created by the developer, he has an incentive to perform according to those goals.

This is not to say that now automatically the goals will be achieved, but you have made a start. So first rule of metrics: Give people control over factors affecting their metrics. When people have such control over the constraints affecting their work, they are the first to ask you to measure them, because they have the capability to improve upon them.

Comments on this entry are closed.

{ 1 trackback }

Previous post:

Next post: