One of the big concerns of companies that employ software engineers has been how to measure the productivity of these people. From a business standpoint, the idea is that one should find ways to maximize the work done by their employees. However, it is difficult to evaluate how this maximization process would happen if no one knows how to measure it.

Performance measurement in the software world is complicated by several issues. For starters, the metrics that have been used by the industry are hardly useful. Here are some examples:

• KLOC (thousands of lines of code): is virtually useless, because it can be easily inflated, and correlates inversely with readability. If you hired a civil engineer, would you pay him by the amount of concrete he used in a building?
• number of functions: similarly to the previous one, it can be easily gambled, because one can create very small functions instead of longer ones.
• number of bugs closed: some developers are evaluated by the number of bugs the were able to close. This can however generate a culture of bug proliferation.
• number of features: probably a more useful way to measure productivity. However, it is difficult to quantify how hard to implement a feature is (for example, generating a report versus writing a compiler optimization step). Also, quality of the feature must be considered as part of the equation. While bug free software is rare, but # of bugs should be as low as possible through careful testing.

In general, the problem of measuring software engineers based on any of the measures described above is that they are smart people. If you give incentives, for example, for writing more lines of code, developers will find creative ways to create more lines than necessary. It is just a fact of life: people align themselves with the rewards.

The conclusion is that measuring productivity is as complicated in software as in any other area of engineering. For example, how can you measure if a mechanical engineer is productive? Maybe by the quality of projects that he finished, but that is not a quickly applicable metric. Sometimes, companies want to look at the job of a software developer as if he or she were a writer — who is payed by the number of words written in a day. That model doesn’t scale, because different pieces of software have different difficulties. Some parts of a program have to be rewritten dozens of times until they are correct. Other parts are pure repetition.

If a comparison needs to be made someone that writes, probably the best model would be a mathematician. A mathematician writes papers, but productivity is not just a matter of typing speed. Mathematicians need to create “bug free” theorems, which take lots of time and craft to write.

The best solution I have seen to this kind of problem is: get smart people to work together, and provide them with a direction. This is how most of the good software we know was created. In fact, having smart and goal oriented people is probably just what you need, because sometimes the directions proposed by business people are not right. It is more interesting to have the right result than a monster that was created according to the view of a clueless manager.

The good news is that some companies already know this lesson. This is the way Google “manages” its developers, and other companies like Facebook, and other startups are following the lead. In the future, if we are lucky, other mainstream companies will adopt this view.

Similar Posts:

• Creative Freedom for Developers
• Finding Ideas for Software Products
• How much code should you write?
• Editing multiple files in a single buffer
• Learning from Great Developers