A Brief History of Software Measurement

The lack of measurement in the field of software development is not due to a lack of resources. There have been numerous books and articles written on software measurement. One of the first books written on measuring the software development process was Software Engineering Economics by Barry Boehm. Back in the early 1980s, Boehm developed the concept of Constructive Cost Modeling where he identifies drivers that impact cost and builds estimating models. Capers Jones has written numerous books on the subject including Applied Software Measurement which is on its eigth edition. Capers makes a strong case for the use of measurement, and especially function points. Tom DeMarco wrote PeopleWare and Controlling Software Projects. DeMarco also makes a case for measurement but does not mention specific measures. He, like Atul Gawande is suggesting measuring something. Charles R. Symons has written a lot on the topic of measurement, and his most significant publication was Software Sizing and Estimating. Symons points out thatwhat gets measured depends on the goals of the organization. Norman Fenton and Sherri Pfleeger do a nice job of outlining how to measure the software development process in their book Software Metrics A Rigorous & Practical Approach. Another book worth mentioning is Katrina Maxwell’s book Applied Statistics for Software Managers. The point in listing all these books and authors is to demonstrate that there are plenty of resources available to those who want to learn to measure the software development process.

While there have been many significant contributions, one has to wonder why measurement is so rare in the field of software development. What is the root cause for this reluctance to measure? The primary reason that measurement is so rare is software developers see little benefit in measurement. They hold a very biased opinion and see any effort to measure as an unnecessary burden to writing code. In their biased world, studying the software development process adds no value, and many hold the false opinion it is not even possible to study the software development process. What they really believe is measurement, systematic study, and the scientific method interferes with the real work which is, of course, writing code. The real work is solving customer’s problems with the least amount of effort. The only way to accomplish this is via systematic study of both the customer and the process followed to solve the customer’s problem.

Another reason given for not measuring the software development process is the software development process is too complex or nebulous to be measured. The software developer prefers to use intuition instead of systematic study. In a method of intuition, what makes logical sense must be true. I have heard many software developers say, “I know what I know.” It reminds me of the lyrics from the song “What I am” by The New Bohemians: “I’m not aware of too many things, but I know what I know if you know what I mean.” If knowledge cannot be communicated via some type of, measurement it is difficult to understand what is meant. If any process is “too complex” or “random” to be studied using the scientific method by applying measurements, then it is a safe bet that it cannot be studied using intuition either.