Metrics
How's Your Metrics Program Doing?
"Everything should be made as simple as possible, but not simpler."
- Albert Einstein
How’s your software measurement program doing? Is it well funded and supported by management, or do you worry about your job the next time the organization decides it needs to be “leaner and meaner”? Many measurement programs are cancelled or fade into meaningless obscurity. Why? Some things are out of your control; but here are a few that will improve your odds for success:
An In-Depth Look at the QSM Database
The QSM Database is the cornerstone of our tools and services, so our clients and prospects often ask for more information regarding the data and types of projects represented. This blog post addresses some frequently asked questions about the QSM Database.
Beyond the Hype: Thoughts on Agile Development
I'm pleased to make available "Beyond the Hype," a presentation that I delivered at the 2011 Practical Software and Systems Measurement Conference. "Beyond the Hype" is a metrics-based analysis of Agile development that both confirms some “common wisdom” and contains a few surprises. Does Agile really have higher productivity? How does Agile quality compare with traditional development? What are Agile’s demonstrated strengths and weaknesses? How can you size and track Agile projects? Using Agile project data from the QSM Database, "Beyond the Hype" addresses these and other questions about Agile.
Simpson's Paradox
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:
Technology Can Only Do So Much
It’s hard to believe it’s been 36 years since an IBM manager named Fred Brooks came out with his seminal insights about software development, the most famous of which ("adding more people to a late software project makes it later") came to be known as Brooks’ Law. These days, most software professionals accept and appreciate Brooks’ analysis, yet we continue to make the very mistakes that prompted him to write The Mythical Man Month!
An Empirical Examination of Brooks' Law
Building on some interesting research performed by QSM's Don Beckett, I take a look at how Brooks' Law stacks up against a sample of large projects from our database:
Does adding staff to a late project only make it later? It’s hard to tell. Large team projects, on the whole, did not take notably longer than average. For small projects the strategy had some benefit, keeping deliveries at or below the industry average, but this advantage disappeared at the 100,000 line of code mark. At best, aggressive staffing may keep a project’s schedule within the normal range of variability.
