​Want agility? Forget those function points!

Until just a few weeks ago, I thought measuring coding efficiency using function points had already been killed dead. Sadly I was wrong. In this post, I’ll share what happened and my two cents on why we should stop digging them up from their grave.

As a Lean-Agile coach at a customer organization I bumped into a few people pondering a request from management. They had been told to implement function point calculation on the code their development teams and release train had delivered during the year. They were struggling to make up their minds on whether to refuse this request or just to comply and provide the data. Long story short, I told them to prepare for a fight. We would show the request was nuts.

I’m sure the management had good intentions. They wanted to see how the release train and the teams were doing. The problem is that the function point calculation will not provide useful data, and it can even be hazardous.

Of course, this is not a unique approach. People in software development have tried to measure the output of programmers in many ways. The first method was to simply measure the lines of code produced in a given amount of time.

But if you know anything about programming, you know the amount of code a programmer can write daily will not tell you much about their productivity - especially if they know that's how they are measured. The same applies to writing: counting the words in a book or a blog post will not help you figure out the meaning or impact of the text.

Function points were invented to quantify the amount of logic in code as a better means to measure productivity than lines of code, as well as means to size up information systems. It was never the perfect solution, but in the world of long waterfall projects better alternatives didn’t exist.

So what's the problem with this request from management? Aren’t function points then the best way to measure how teams are doing? Well, no. Here’s why function points can't measure team performance:

1. Agility is built on the realization that to create value, you need both the business acumen to come up with a valuable idea and the capability to implement that idea.

Your business can come up with killer ideas that aren't even remotely implementable. You can also have superior programmers whose output of smartly written code (and function points) is off the record, but if you spend that programming power on creating the wrong thing, you still get nothing of value. In both cases, parts of your system are working wonderfully, but the end result may still be a failure.

2. The best ideas and implementations are often simple. Less code (and function points) may really mean more value.

That doesn't mean there wasn't a lot of effort behind most simple and elegant solutions. The team and the business may have gone through several different approaches before finding the one that works. Also from this perspective we have nothing to gain from knowing if we've produced more or less function points this month compared to earlier times.

3. Measuring the wrong thing leads to optimizing the wrong thing.

I would hate to see teams try to come up with more function points instead of more value. So not only is the value of function point data low, there’s also a big risk in relying on it.

While function points still exist I’m definitely not alone with wanting to get rid of them: a joint study by different European universities stated that expert based estimations are more accurate than those obtained by means of models, calculated with functional size measures. The study in question was repeated in several different web development projects with and without the GUI component.

If you're looking for better ways to measure your or your team's development, consider joining one of Nitor's courses.