Defining the X-factor: What is an ounce of software worth?

Defining the X-factor: What is an ounce of software worth?

Ask how big a software project was, and we will often hear, “Oh, about 11,000 hours.”
Huh? Size doesn’t have units of time. How big was another 11,000-hour project that was canceled without producing any software? Or a third 11,000-hour project that produced only “a little bit”of software, but software that was extremely profitable? There’s an intuitive sense of software size, but without a measurable “ounce of software,” we’re left with hand waving.
Hand waving is a problem for a software-intensive business, since businesses are managed by numbers. Most management numbers are ratios: gross profit to revenue, return to investment, hours per X, and defects per X. According to Jim Collins, Good to Great companies clearly understand their X, and how to sustainably grow profit per X.
A software-intensive business would benefit knowing productivity (effort or cost per X), quality (defects per X), maintainability (X per FTE), and business impact (revenue or cost reduction per X) where X is the elusive “ounce of software.”
What’s a good X for a software operation? It will be independent of technology. It will encourage good project management, especially scope/schedule tradeoffs. The thinking goes as follows: “If we need to ship in four months, not six, we need to drop enough features to reduce X by one-third.”
It would help answer executive questions and evaluate vendor claims about productivity and quality. “Our cost per ounce is down 30 percent since we switched to HypeMeister, but our defects per ounce went up 10 percent.” The cost of measuring must not be more than the information is worth. And ideally the “ounce” is a standard to allow benchmarking.
The ISO standard gram of software
There is such a thing as an ounce of software. It’s called a Function Point. Maybe it’s more like a gram, since it’s now an ISO standard (ISO/IEC 20926:2003). Function Points originated inside IBM over 30 years ago, and the ISO standard version is maintained by the International Function Point Users’ Group.
Function Point Analysis (FPA) identifies and quantifies the data flows in and out of an information system, and the information types read and modified. Function Points are independent of technology. They can be determined from existing software, functional specifications, and even (with some assumptions) early project concepts.
FPA complements and strengthens requirements gathering and analysis, regardless of methodology (waterfall SDLC or iterative), with an added cost of less than five percent. There are published benchmarks such as ISBSG, and a marketplace of consultants with their own proprietary benchmarks.
Why aren’t Function Points widely used? IFPUG’s Counting Practices Manual is intimidating at first, but once learned, FPA becomes a natural part of requirements analysis. The rules are subjective – highly structured, but still subjective – and that puts some people off. Sadly, some people don’t want to know. Management has to actually let the data shape decisions, or FPA is a waste of time.
Maybe Howard Aiken was right when he said, “Don’t worry about people stealing your ideas. If your ideas are any good, you’ll have to ram them down people’s throats.”
Adopting Function Point Analysis
Effective adoption should involve the people who will use the results – those who make decisions about estimates, schedules, tools, and methodologies. The learning curve is short but steep, so it’s best to identify one enthusiastic person and get them some training. Business analysts are good candidates. Small or agile-method shops (without requirements specialists) can tap that senior developer who enjoys evaluating, sizing, and prioritizing the user stories, features, or whatever form requirements take.
Function Points are best understood by example rather than explanation. A good place to introduce them for immediate effect is project estimation. Choose a project that’s just getting underway. Select several comparable projects based on team, technology, and overall character, and count the FP delivered by those. Also, reconstruct the effort expended (that alone can be enlightening), and that will give you several productivity (h/FP) numbers. Then count the subject project’s requirements and multiply to get a metrics-based estimate.
Immediate benefits
Two immediate benefits are confidence and traceability to requirements. If you are the skeptical project sponsor, you can see where the estimate came from and how much to believe it. If you are the pressured project manager, you can point to the project history and the FP count of the current requirements. Rather than playing “schedule chicken,” you can recommend scope reductions to decrease the count.
And when someone asks you, “So, how big was that project?” you can say, “Well, it started at 550 Function Points, but we cut it to 400 on account of the trade show. Even so, we had to put two extra people on the team, so our productivity took a hit. I could tell you our average productivity in hours per function point, but then I’d have to kill you.”
Nudge, wink.
Related articles
Kirk Knoernschild: Agile Revolution: A new era of software delivery
Geoff Bastow: Web-centric entrepreneurs find models that attract investment
Got bugs? New project lets real computer users gang up on software bugs
Company issues warning on outsourced software
Gates displays software’s future to UW-Madison students

Robert Merrill is the Principal of uFunctional, LLC, a Madison software development consultancy. Merrill has been applying metrics-based software estimation techniques since 1998, and has been an IFPUG member since 2000.
The opinions expressed herein or statements made in the above column are solely those of the author, and do not necessarily reflect the views of Wisconsin Technology Network, LLC.
WTN accepts no legal liability or responsibility for any claims made or opinions expressed herein.