Original Post Date: Tuesday, June 5, 2012

Ever wonder what programming languages are the most productive?  I recently did a little research into this topic using the International Software Benchmark Standards Group (ISBSG) database. The database contains over 5000 data points with size and effort data for projects from a wide variety of industries, applications and counties.  Of course not all 5000 data points were suitable for my investigation.  The software size is measured using functional size metrics but the database accepts projects that use various counting methods.  I narrowed my search to projects that used the International Function Points Users Group (IFPUG) definition of a function point.  The database also accepts incomplete project data, asking the submitter which of the following phases of software development are included in their submission: planning, design, build, specification, test, and implementation.  While many of the data points reflected complete lifecycle effort, those that did not needed to be normalized to enable a side by side comparison. 

I started by calculating average productivity (hours per function point) for each programming language that was suitably represented in the database.  This led to results that were statistically all over the place.  So I changed it up a bit – looking at average productivity rates within size stratifications.  This led to results that appeared much more reasonable to me.  And for the most part the productivities were as expected but one finding from this study was particularly interesting.  For pretty much every language the least productive projects were the smallest ones.  This seems counterintuitive because most studies indicate a diseconomy of scale in software projects.  The ISBSG database does provide for new projects and enhancement projects but it is not easy from the data that’s submitted to determine concretely how much reuse a project includes regardless of whether it’s new or an enhancement of existing software.  So this may be an indication that larger projects have more opportunities for reuse.  Whether or not this is true, the following table can certainly be used for sanity checks as one is estimating their software projects.  This is also a window into the types of data that are available through the ISBSG.  If you’re interested in a more detailed analysis of some or all of these 5000+ data points – check out what the ISBSG has to offer at www.isbsg.org