Can one measure productivity in IT?

In software engineering we have a technique called Function Point Analysis (FPA) to work out the functional size, productivity, cost, time-lines, and even expected error rates. It falls under the banner of Quantitative Software Estimation. It is a bit like what quantity surveying is for the building industry.

Function Points provide a “unitary measure” of functionality, which is equivalent to "square meters" in the context of building a house. And like we can say for a house, “a square meter costs anywhere from $X to $Y to build", in software engineering we can do the same for software using Function Points. Function Points are counted, or measured, not estimated! What is estimated is the effort, duration, defects etc, once you know the “meters” / functional size of the software (expressed in Function Points).

Where the Function Point tells us the functional size, the computer language(s) you implement this functionality in, determines the productivity. A 3rd generation language like C# or Java is far less productive than a 4th generation language like Standard Query Language (SQL), such as you get with Oracle Forms.

The measures of effort by Function Point for a computer language are not linear, so you need a quantitative estimation tool to compare. These tools typically contain a database of data from many tens of thousands of projects built in various languages. The Rolls Royce of tools is QSM, but a very useful second is Construx, and you may even have heard of and used CoCoMo. The ultimate of software metrics comes from a man named Capers Jones of Namcook, and some of his freely available benchmark data is used here.

Do you need help to argue your case? Ask us ✉.

Doing the metrics for a real, large, VBA project

During 2022 we (two associates and myself) worked on a large functionality VBA-tools for a big global bank in New Zealand. At one stage the bank’s management felt it was all taking a bit long, till I dusted of my FPA skills, counted this complex Market Risk tool, and showed how productive we had been! Any other language choice would have taken longer, would have required more developers and testers, and would have yielded a multitude more defects.

My background

I was trained in FPA counting in the mid 1990’s, and by 2015 I had performed well over 60 Function Point counts on large systems  of 1000 to 8000 FPs. I have used the QSM and Construx tools for projects estimations, RFP evaluations, and dispute advice.

Here is how I went about it

I roughly counted this system, as it takes too much time to do it completely and erred on the side of caution. I then stuck the FP count result through the Construx estimation tool and applied the Capers Jones defect statistics of 2012 (there may be newer, but I don’t have those).

Size characteristics for this project

1.       Functional size : 2,200 adjusted Function Points.

2.       75 tables of data.

3.       45 files to be read, and enriched (data conversions, data expansion etc).

4.       25 reports to be created, each report comprising of six or more report tables on a page.

5.       Unadjusted, the size is around 2,500 Function Points (+possibly another 300).

6.       The Value Adjustment Factor (VAF) for system complexity brings that down to roughly 2,200 Function Points (VAF is the qualitative expression of how user interactive and unattended the system functions).

The result

So how productive is VBA?

Insanely. These metrics shows what an excellent choice Excel has been for this project, and how incredibly productive Excel is versus Python, which by the way, is more productive than Java or C#.

The reason for the high productivity is that Excel provides you a complete UI to edit any table, cell, you name it, as well as a huge library of componentry code to directly interact with Excel, Windows components, the File system, etc., for free, out of the Office 365 box. The functional size provided / embedded in Excel is huge, and thus one only needs to add a little, to get the functional size you need for your product.

The message should be: Who cares what language it is developed in, what matters is that your business issue is solved at the lowest cost and least amount of time, not so?

Have a look at the sort of projects we do to help customers solve gnarly business issues with Excel, at considerably lower cost, and much shorter timeframes, than involving the IT department and development vendors.

Below the supporting metrics-data snapshots

Construx modelling:

Defect analysis using Capers Jones (with thanks!)