This is my personal thoughts, opinions and musings place. I will also rant about things, especially politically-correct things that irritate me. And sci-fi. Did I mention sci-fi? There'll be lots of sci-fi stuff here. And movies, too. Mmmmm... Movies

Tuesday, May 31, 2005

Of Function Points, and the attendant reduction in developer performance

This is a belated continuation of my article on CMM.

One of the myths in the software development industry, especially large software development industry, is that standardized measurements of system size and complexity are possible across different development environments. One such system of measurement is called “Function Points”. Developed initially by IBM(I think!!), it has been adapted by quite a few large development houses, and if my experience with it is any indication, it is no more accurate there than it has been here.

To understand the problem, I suppose I should explain what Function Points are. Please note that I'm not an expert on FP, and merely relating what I have seen. FPs, at their simplest, attempt to measure the size and complexity of a given system. This is done by assigning points to specific types of functions that your software performs, then by adding an adjustment factor to the total, and presto! you have a number. How is all this done? Well, every data input and look-up screen is analyzed for functions performed, numbers of files/tables accessed, and number of fields on the screen that can be edited or are display-only. Every report produced and every batch process is also counted in a similar way.

So, the end-result of all this effort is a number. Let's say it's 14,000. “But what does it mean?” you ask. Surprisingly, it means absolutely nothing. Unlike, say, a voltage reading of 9 volts which is an absolute, a function point count of 14,000 means diddly, unless you compare it to something else, say a function point count of 9,000. So, given those two numbers, you can say that that the software that counted 14,000 FPs is larger and more complex than the software that counted 9,000, right? In the real world, you would be correct, but this isn't the real world, this is the world of bureaucracy.

The trouble is that these numbers can only really be compared between very similar systems. Let's say you wrote two systems. The first system consists almost entirely of data input and inquiry screens, and the second system consists almost entirely of batch processing and reporting functions. That first system with mostly input screens will result in a much larger number of function points than will a batch or a reporting system, because FP counting is is biased towards online, data-input systems. In the immortal words of Yoda the Jedi Master, “No, no, there is no why!” On top of all that, there're also different ways to count FPs, and they're not always compatible.

Now, you may be asking yourselves(always assuming you actually read this far), why is any of this a problem? It certainly makes sense for a development house to know how large and complex their systems are, so what's the issue? The issue isn't FPs themselves, or how they're counted, the issue is how they're used.

As with any initially good idea, once the bureaucrats get a hold of it, it all goes down hill. So, at the company I do work for, the big thing is FPs per developer. The higher the FPs the better, since the developer is producing more output over the same amount of time. This is where they get into trouble. Since online, screen-based systems produce far more functions, these kinds of developers tend to have a much easier time meeting their performance goals. The batch-based developers may be maintaining systems with hundreds of thousands of lines of code, they need to produce more and more to make up the difference in system methodologies.

It would be logical to assume that companies are aware of all this, that they'd make allowances for those developers not working in FP-rich environments, but the assumptions would be incorrect. Worse, developers feel they need to artificially raise their FP counts, so they create new functionality that, strictly speaking, isn't necessary for the business. Where one screen with expanded functionality would do just fine, they write two screens because that gives them more FPs. And that, of course, results in reduced developer efficiency and a more complex and unwieldly system to maintain.

Software development is a horribly complex and difficult process, so much so that few people realize just how complex and difficult. If done properly, however, it is also an extremely fun and exciting way to spend your working life. Few things are as gratifying as seeing your work being used by people. But these latest initiatives that many companies have undertaken, including CMM and FPs are destroying all the fun. Stay tuned for another article on the insanity of modern software development.

0 Comments:

Post a Comment

|

Links to this post:

Create a Link

 

Copyright © 2005 Yury D.   All Rights Reserved