Why It's Time for FP++

Finding a measure to effectively size applications has never been more complicated: Here's how using a 30 year old concept can help.

Enter Function Points

Developed by Allan Albrecht for IBM in the 1970s, function points were designed to solve the problem of quantifying the size on an application's functionality. While not getting into the nitty gritty of the specifics of how they work, function points are counted for an application based on a set of rules. The rules are related primarily to data flowing in and out of the application. By counting the function points of an application, you can gauge the size of an application's functionality and use it for the purposes listed earlier.

Some of the specific merits of the function points counting approach include the following:

  • Consistency. Function points are designed such that if two independent analysts do a count of the function points within an application, they should arrive at a very similar result.
  • Life-cycle friendliness. Function points can be counted at any point during the life cycle, from requirements gathering or at a completed and deployed application.
  • Independence. The nature of function points is that they're independent of other development factors (time, personnel skill sets, investment dollars, lines of code, architecture platforms, and so on).

Time for FP++

Because it's been nearly 30 years since function points were created, they have some deficiencies with respect to modern day development. First, function points worked well when enterprise applications consisted primarily of data coming in through screens, simple processing (either online or in batch), and data then going out via screens or reports. Although not specifically stated in the literature, it seems clear that function points were also designed under the assumption of structured analysis and structured design on a mainframe system.

Today's applications can be Web based, use frameworks and third-party packages, run on many different platforms, be available continuously, integrate with known and unknown partner systems, include complex algorithms, and reside in complex architectures. Although the function points specification does provide a list of catch-all adjustments that can be made after the base count to account for complexities in the software (especially complexities unforeseen when the function point counting method was originally designed) these adjustments aren't commonly used, and when they are used, they're subjective and, thus, result in inconsistent counts.

Additionally, it's often laborious and expensive to conduct a function point count, especially on preexisting software. Most important, the preeminent function point showstopper is political. Because it hasn't been accepted into the mainstream, function point count use is so limited that many managers don't see the need to learn to do the counts and use them.

What the ++ Entails

In the spirit of a columnist, the strengths of my capabilities lie more in pointing out problems than in solving them! Because I don't have a solution to determine how to either extend function points or take a similar approach that would be as effective at measuring application functionality sizes in today's environments, I'll present a few additional requirements that draw upon the key merits of function points (consistency, life-cycle appropriateness, and independence):

  • The application functionality sizing should be consistent regardless of the technology used for development.
  • The application functionality sizing should take into account integration with other systems, service-oriented architecture usage, and the use of frameworks and third-party software.
  • The sizing process should handle efforts that target applications with different expected longevity appropriately (such that quick-and-dirty applications are sized smaller than applications that you expect to be in production for many years).
  • The quantification of the functionality size of a completed application must be able to be automated. It would be especially slick if tools such as UML designers could provide this capability as well.
  • Developing software for reusability should affect the application functionality size.
  • The sizing of more complex algorithms (I envision a relative scale based on a number of standard algorithms that can be used as comparison points) should be handled in a way that it appropriately affects the application size.

I hope that a reader who's smarter and more capable than I am (or at least one who has more spare time) will be able to develop a way to size applications within the boundary of these requirements. IT managers will celebrate in the streets once they have the ability to accurately measure an application's size and use that information to measure their departments. In the meantime, I'll keep looking for meaning in my ability to finish this two man-hour column in less than 90 minutes.

Robert Northrop was formerly a director of design and development with Tallan, a professional services company specializing in developing custom technology solutions for its clients. Northrop now is an MBA student at the University of Virginia Darden Graduate School of Business Administration.


  • Brooks, F.P., The Mythical Man Month, Addison Wesley, 1975.
  • The Function Point FAQ
  • Garmus, D. and D. Herron, Function Point Analysis: Measurement Practices for Successful Software Projects, Addison Wesley Information Technology Series, 2000.