June 16, 1999 Advisor

At a recent conference on software measurement, several industry experts, including Tim Lister, Tom DeMarco, Bob Grady, and David Card, were asked to discuss the software triangle: should the focus be on people, process, or technology? The ensuing discussion with the experts and audience participants was fast-paced and opinionated, with views ranging from equilateral triangles (focus evenly on each component) to 3-D pyramids. At several points during the discussion, parallels with engineering and construction were mentioned, as were ideas about how a particular focus could solve the ailments of the industry.

Predictably, the session ended without consensus or concrete solutions, and the conference moved on to other topics. But long after the ballroom emptied out from the panel discussion, I continued to ponder issues that came to mind during the dialog:

1. The software triangle seems too simplistic an answer to the complexities of software development, yet most participants seemed convinced that there was a "magic" formula to balancing people, process, and technology. It struck me that our engineering and computer science backgrounds often lead us to believe that everything in software can be solved through linear equations and concise models. Predictable, scientific endeavors lend themselves to mathematical solutions, but software involves degrees of human interaction that are not easily captured through linear equations. If there was an easy, one-size-fits-all, measurement equation to solve our system development problems, I believe we would have found it by now.

2. Comparisons between engineering and software and between construction and software development are concepts that deserve further exploration. Although software engineering is often compared to other engineering disciplines, a major difference lies in the fact that software is not constrained by the laws of physics. Still, our industry is learning that consistency and process improvement emerges from applying the repeatability of engineering processes to software, and this is progress.
The comparison between construction and software development gives rise to interesting differences. For example, construction never commences without floor plans and sealed engineered drawings, while software often commences before solid requirements are documented. In construction, building codes govern the construction process; software development proceeds fundamentally without such a code. However, the similarities between the industries are striking:

Seeing these similarities leads me to wonder whether software measurement could be used to establish traceability checkpoints during development, similar to the building code inspections.

3. The fundamental issues in software development haven't disappeared with the emergence of newer tools and technologies. We are still challenged to deliver accurate estimates, define complete requirements, and control and track scope changes. However, through appropriate measurement and process improvement initiatives, there is promise that these aspects are becoming more controlled and manageable, one project at a time.

The most promising idea that emerged from the overall conference was that properly implemented measurement programs can provide answers to some of the most elusive software questions through tracking of project outcomes. Measurement is essentially an audit trail of the development process, providing key indicators that can lead to process improvement. As past performance is often a better predictor of future projects than are theoretical models, measurement can add predictability to the software process, thereby increasing a project's overall chances of success. Is it time for your company to explore how measurement can help your development processes?

 

Measurement is no silver bullet | Gauging the Size of Software Projects
Where does Measurement fit in the development process?