On Oct. 2, 11:00 AM EST, QSM's Phil Armour will present "A Practical Approach to Measuring Software Development Productivity" as part of the ITMPI Webinar Series. 

Most measurements in software development are notoriously difficult and assessing productivity is no exception. There are an enormous number of factors that could or do affect productivity, and it is challenging to identify and characterize what they might be. The effort involved often deters organizations from even attempting to quantify how effective they are at building systems. This webinar will present a useful and practical approach to productivity measurement based on a mathematical model of systems development and over thirty years of research. It will also describe the core mathematical functions that relate to the major attributes of systems development, show how a useful productivity metric can be calculated from project history, and demonstrate how QSM’s database of over 10,000 projects support this view of software development productivity.

Register now!

Recently I conducted a study on projects sized in function points that covers projects put into production from 1990 to the present, with a focus on ones completed since 2000. For an analyst like myself, one of the fun things about a study like this is that you can identify trends and then consider possible explanations for why they are occurring. A notable trend from this study of over 2000 projects is that productivity, whether measured in function points per person month (FP/PM) or hours per function point, is about half of what it was in the 1990 to 1994 time frame.

Median Productivity

Part of this decline can be attributed to a sustained decrease in average project size over time. The overhead on small projects just doesn’t scale to their size, thus they are inherently less productive. Technology has changed, too. But, aren’t the tools and software languages of today more powerful than they were 25 years ago?

“You can’t know where you’re going until you know where you’ve been.”

At this point, we’re about one month into 2013 and many of us have abandoned our New Year’s resolutions.  Personally, I prefer to set my yearly goals about a month in because it gives me some time to reflect on what I really want to improve without being distracted by everyone’s bandwagon resolutions like getting in shape or eating less junk food.

The other reason I prefer to wait a month before resolving to do anything is because it gives me time to collect some baseline data.  In his Wall Street Journal article, Bill Gates writes, that “you can achieve incredible progress if you set a clear goal and find a measure that will drive progress toward that goal.”

To use the common example of getting in shape, I’m going to explain:

1. How to set a goal, and
2. How to measure it so that you can effectively achieve your goal.

First you need to set a baseline measure of what your abilities are.  How fast and far can you run?  How much weight can you lift?  How much do you weigh?  Knowing the answers to these questions can help you determine what needs improvement.  

Next you need to identify your end goal and find a way to quantify progress towards that goal.  What does “get in shape” actually mean?  Do I want to be able to run faster?  Farther?  Do I want to be able to lift more weight?  Do I want to weigh less?  All of these goals can be quantified (e.g. I want to be able to run a mile 30 seconds faster than I currently do, I want to run a 10 miler, I want to be able to bench press 100 pounds, I want to lose 20 pounds).

On Thursday, Oct. 6 at 1:00 PM EDT, QSM will host a webinar focused on the relationship and apparent paradox between software size, productivity, and reliability.

Now, more than ever, software projects need to efficiently deliver reliable software. However, many development plans unintentionally guarantee a less than optimal result. This presentation describes how to maximize value by establishing minimum acceptable reliability and how to take advantage of the apparent paradox between software size and productivity through appropriate selection of team size and schedule duration.

Paul Below has over 25 years' experience in measurement technology, statistical analysis, estimating, forecasting, Lean Six Sigma, and data mining. He serves as a consultant for QSM, providing clients with statistical analysis of operational performance for process improvement and predictability. Mr. Below is a Certified Software Quality Analyst, a past Certified Function Point Specialist, and a Six Sigma Black Belt. He has been a course developer and instructor for Estimating, Lean Six Sigma, Metrics Analysis, Function Point Analysis, as well as statistical analysis in the Masters of Software Engineering program at Seattle University. He has one US patent and two patents pending.

View the replay of this webinar.

Last week we looked at IT software productivity trends for 1000 completed IT systems and noted that average productivity has declined over the last 15 years.

The post sparked some interesting responses. Two readers wanted to know whether productivity actually increases over time for projects in the same size range? If so, this would be an illustration of Simpson's Paradox: a counterintuitive phenomenon we've seen from time to time in our own research. Simply put, sometimes the direction of a trend is reversed when the sample is broken into categories.

To answer their question, I used our SLIM-Metrics tool to stratify the sample into four size bins:

Under 5000 Effective (new + modified) SLOC
5000- <10000 Effective (new + modified) SLOC
10000-<20000 Effective (new + modified) SLOC
20000-<30000 Effective (new + modified) SLOC

These 4 size bins span a little over two thirds of the data. As a sanity check, I applied the same queries to both the original sample of 1000 IT projects and a larger sample of nearly 2200 IT projects. As the following chart shows, stratifying the data into size bins doesn't affect the overall direction of the trend:

For conventional productivity (FP/Person Month) the decline in productivity was even more pronounced:

Here are the results as of 3 pm today for our productivity poll. I was surprised to see that "Time slicing and multi-tasking" was far and away the most popular response!

When I framed the poll question, I was thinking of time slicing by policy (i.e., where management asks a single person to divide his time/attention between multiple projects). Viewed from a cost perspective, such assignments make perfect cents [pun fully intended] - especially for small or poorly capitalized projects. But from a productivity perspective, the constant distractions inherent in this kind of multi-tasking can result in less than optimal performance. 

Carol Dekkers made me think of another possible explanation for the declining productivity we've seen over the last 15 years: the distraction of 24/7 online communication. 

Since joining the world of social media I realize my “connectivity” has grown exponentially, but not all in a good way. Even with my SPAM filters set to high, I get so much email that it is overwhelming!

 I feel like I must have ADD (attention deficit disorder) because my day is interruption after interruption (sorry TweetDeck!) and I need help (and I know I am not the only one!)

On our Software Productivity Declines Over Time post, ISBSG's Peter Hill left an interesting comment:

... your findings that 'average productivity increases with project size' might raise a few eyebrows, but the ISBSG data produces the same finding. Of course we only have data on projects that were completed. I wonder about the incidence of abandonment of large projects.

The QSM database shows a positive correlation between system size and productivity. The following chart shows PI vs. System Size regression fits for 9 different application domains (Business, System Software, Process Control, Telecom, Scientific, Command & Control, Avionics, Microcode, and Real Time). Regardless of domain, average productivity increases with system size:

View larger image

In the SLIM-Estimate user's guide, we speculate about possible explanations for the relationship between productivity and system size:

Small systems tend to have lower average PIs than large systems. We can only speculate as to the reasons, but two important influences may be management influence (the way large and small systems are planned, managed, and funded) and economies of scale.

Since we're speculating about why (in the aggregate at least) software productivity appears to have declined over time, here's another possible cause. I call it The Housework Theory of Productivity.

Back in great-Grandma's time, cleaning was a labor intensive endeavor. Rugs were swept once or twice a week and taken outside and beaten by hand once a year. Those cheery little scrubbing bubbles weren't around to whisk the pesky soap scum from our bathtubs - they hadn't been invented yet. When it came to cleaning, our aspirations were limited by the time and effort required to complete even the simplest tasks.

Over time various "labor saving" devices ushered in heretofore unheard of levels of springtime fresh cleanliness. But there was a downside to these advances: as our ability to get things clean increased, so did our expectations. The work expanded to fill the time (and energy) available to us.

If we were to compare two software projects that are same size and perform the same function (but were completed 20 years apart), we'd likely find the modern billing system smaller in size but far richer in features. It would also be more complex, both from an algorithmic and an architectural standpoint. Because today's programming tools and languages make it possible to deliver more value per line of code or function point, our standards have risen. We expect more for our time and money.