Sometimes business life follows literature. Recently, I came across the following quote and I had to pause:
“Before we build a better mousetrap, we need to find
out if there are any mice out there.” - Yogi Berra
It reminded me of a conversation I had over lunch 15 years ago, when I was president of the International Function Point Users Group (IFPUG) and Charles Symons was president of the UK Software Metrics Association (UKSMA), where we were talking about the future of software sizing. IFPUG is the inventor of the original method to size software using a measure called “Function Points.” Charles is the creator of a similar UK method called Mark II function points and a co-creator of the Common Software Metrics International Consortium (COSMIC) sizing method that was, at the time, still in its infancy. I’m paraphrasing with the words but I believe it captures the content of our conversation:
“The problem with function points,” Charles remarked, “is that they aren’t yet perfect enough. What we need is a better mousetrap and the world will beat a path to our door.”
I disagreed saying “I don’t think that’s the problem at all – I think the problem is that world doesn’t yet see mice as a problem.”
Since then, there’s been marginal growth in function point interest (it goes in spurts), but I believe that both Charles and I were wrong in our predictions of the future, for different reasons. Charles went on to develop COSMIC (now supported by measurement manuals as large as the IFPUG manuals supporting the original method) and gained some market following. We, in IFPUG, spent money on marketing efforts that increased the interest in new markets (such as Brazil and Korea) and applications (such as outsourcing measurement.) BUT in the last 15 years, worldwide, the penetration of functional sizing remains below 10%.
I believe that the software world does see a need to size software portfolios and projects, but hasn’t yet realized:
- There are alternatives to the still popular and unstandardized SLOC (source lines of code) measure;
- What function points are and how they can provide an objective measure of software size;
- Software size is independent of methods and is still relevant in new technology (agile methods propose effort based metrics such as story points);
- Most C-level executives want quick, inexpensive, and silver bullet measures that don’t cost time and effort to implement. In addition, when measures such as function points are proposed, consultants often propose “exact hand counting” that turn off many potential adopters.
In addition, function points seem to be one of the best kept secrets in software measurement: as many as 90% of the companies I meet during project management training have never heard of function points. I believe the biggest challenge always has been: “While the world knows that mice pose a problem, few people know anything about mousetraps.”
Function Points create solutions
The “mice” in software development is the elusive size of the software product. Everyone who buys or builds software wants to know how big it is (quantitatively) because the larger it is, the more it will cost and the longer it will take to build. Traditionally, source lines of code (SLOC) in terms of logical source statements were used to quantify software size, however, SLOC rewards “spaghetti” style programming where the software size grows with the number of “lines.” There are several problems with SLOC counts:
- Programmers who build inefficient software (i.e., routines with lots of extra source statements) appear more productive.
- Every time the programming language changes, the SLOC count will be scaled differently (i.e., 10 lines of Java code do not deliver the same value as 10 lines of Cobol code).
- There are no standards for counting SLOC.
Function points (FP) are a measure of software size that is independent of the programming language used to build the software, and is based on quantifying “what” are the business processes and procedures provided by the software (i.e., what the software does in terms of functionality.) IFPUG maintains the counting methodology (the steps and the values to assign to functions) and the method has stabilized to the extent that there are major industry databases of completed FP counts for all kinds of delivered software.
Function points are akin to square feet in building construction and provide an objective business focused unit of measure that is easily understood by both the business and software developers. In the same way that estimates can be made to build a certain type of building based on its size (square feet) plus the building code, type of building, building approach and other factors, software development estimates can be made to build a certain type of software based on its size (function points) plus its non-functional requirements (quality, performance, etc.), methodology, and other factors.
Function points provide a new “mousetrap” that is economical, easy to learn, and consistently solves the software sizing problem. Since mice (software size) continue to be a problem – why not take a look at function points as a proven solution?
For a primer on function points and how they can be used, please contact us.