Several weeks ago I read an interesting study on finding bugs in giant software programs:

The efficiency of software development projects is largely determined by the way coders spot and correct errors.

But identifying bugs efficiently can be a tricky business, when the various components of a program can contain millions of lines of code. Now Michele Marchesi from the University of Calgiari and a few pals have come up with a deceptively simple way of efficiently allocating resources to error correction.

...Marchesi and pals have analysed a database of java programs called Eclipse and found that the size of these programs follows a log normal distribution. In other words, the database and by extension, any large project, is made up of lots of small programs but only a few big ones.

So how are errors distributed among these programs? It would be easy to assume that the errors are evenly distributed per 1000 lines of code, regardless of the size of the program.

Not so say Marchesi and co. Their study of the Eclipse database indicates that errors are much more likely in big programs. In fact, in their study, the top 20 per cent of the largest programs contained over 60 per cent of the bugs.

That points to a clear strategy for identifying the most errors as quickly as possible in a software project: just focus on the biggest programs.

Nicole Tedesco adds her thoughts:

Sizing is arguably the most challenging part of any software estimate. Without a notion of functional size, managers may find it difficult to negotiate realistic schedules based on their demonstrated ability to deliver software. They are unable to show empirically why the twelve person team that worked so well on a 150,000 ESLOC project over six months not only fails to deliver a 75,000 ESLOC project in half the time, but produces an error-ridden product that infuriates the customer. Unlike manufacturing shoes, software development is full of non-linear relationships between size, time, effort, and defects. What data driven estimation does successfully is arm managers with the ability to sanity check their current plans against past performance and negotiate achievable outcomes based on a realistic assessment of how much functionality can be built with a set time frame and resource profile.

So how do project managers get a better handle on size? The best place to start is with establishing a practical method for size estimation.

Read the full white paper!

Progress, far from consisting in change, depends on retentiveness. When change is absolute ...no direction is set for possible improvement... when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it.

- George Santayana, The Life of Reason

The French have a saying: "Plus ca change, plus c’est la meme chose".

That time tested axiom aptly summarizes QSM's 30 years of experience in the software industry. In the three decades since a senior Army Colonel first explored the relationship between software size, schedule, effort and defects, Larry Putnam’s original work has been refined, retested and ultimately reinforced by the dizzying pace of modern software development. Tools and methods du jour continue to replace their predecessors in quick succession but our research shows a reassuring constancy in the fundamentals of software development.

In retrospect, it is not surprising that Larry's work stood the test of time. His approach - practical, results oriented software measurement - was dictated by a feeling familiar to beleaguered developers: pain. When he arrived at the Army Computer Systems Command in the mid-1970s, software cost estimation relied on a simplistic productivity measure: lines of code per person month of effort. Dividing this ratio by the estimated size of the contemplated software product yielded total effort, which could then be divided by planned effort resource gave a schedule estimate that could be tweaked if needed.