DEADLINE, chapter 12. How deep do metrics delve?


This chapter has another of those moments in which something or someone is introduced as mostly irrelevant, but turn out to be a big deal in our reality. It happened before with the introduction of the NNL (Bill Gates) and now it happened with a ’charming small company’ that turned out to be none other than IBM.

“IBM” flickr photo by Open Grid Scheduler / Grid Engine https://flickr.com/photos/opengridscheduler/22848635441 shared into the public domain using (CC0)

T. Johns Caporonus was the trigger this time. This man was the consultant of the company that created a unit that determines the size of a software product entirely from the outside. These units are called ‘function points’. Mr. Caporonus went to Morovia and had a long session of research and calculations with Webster and Gabriel which resulted in a little chart that displayed the sizes of each of their products in function points.

When Belinda showed up, she was amazed at how useful function points could be. She immediately made a correlation between those units and their simulation model. A lot of information can be retrieved from such measurements, for instance: how productive the company is or how much certain product will cost.

Function points are an actual unit of measurement that express the amount of business functionality, an information system (as a product) provides to a user. They were originally created by Allan Albrecht from IBM in 1979 and are currently accepted as a standard in the industry. As of 2013, there are five ISO standard specifications regarding function points, this website has some information about them, as well as a more detailed explanation of how FP work.

According to Mr. Tompkins, Caporonus spat out several statistics and pieces of information that could be useful to them. I found this document that takes data from years 2000 and 2006 and includes several charts that summarize some statistics regarding one of the five ISO specifications of FP: IFPUG. Some of the most interesting facts that I gathered are:

  • Japan had the highest average cost per FP: $1600 USD.
  • Mexico had the ninth lowest average cost per FP: $200 USD.
  • The book states that the average cost per FP was $1050 USD in America as of 1994. It hadn’t changed much, since as of 2000, it was $1000 USD.
  • The programming language with the highest average number of lines of code per FP is any Assembly Language with 320 lines, followed by C with 128.
  • The average cost per FP for implementation is as four times bigger than for development for the same project.
“Data-Analytics” flickr photo by learn_tek https://flickr.com/photos/153724200@N07/40932460914 shared into the public domain using (CC0)

Data is valuable, and this system of metrics could give them a lot of it. Belinda saw its potential and was eager to retrieve information from previous projects. In order to get it, though, a lot of research was needed. They needed somebody capable of digesting data and knowing whom to go after to get it: an ‘archaeologist’, as they called it. Waldo was chosen for this position and was promoted to manager of the metrics group. According to Wikipedia, even now the cost per unit is calculated from past projects, so this archaeology thing may be pretty helpful for them.

Belinda suggested that even if they hadn’t come across the function points from Caporonus’ company they could have created their own unit for measuring their projects. Maybe it wouldn’t be as precise or wouldn’t consider as much variables, but it would’ve definitely served its purpose.

A handful of other units of software metrics exist. Many of them have different approaches, and some others try to solve one of the FP’s main weaknesses and take algorithmic complexity into consideration when measuring a product. The one thing they all have in common is their main goal: see the whole picture and understand costs, analyze productivity, identify areas of improvement and determine the quality for certain piece of software. According to this article, having this kind of measurements can help a lot: 75% of the projects that use FPA are delivered on time, in contrast with 45% for the projects that don’t.

As Mr. T said in his journal: sizing products is a great practice. It doesn’t matter if completely objective measurements are available, subjective ones can work in the meantime. An idea of how well some product is doing in relation to its size can’t be a bad thing to have.

“ruler” flickr photo by shoadoadgth https://flickr.com/photos/185630370@N04/49113597878 shared into the public domain using (CC0)

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: