by Arlene Minkiewicz
| September 18, 2014
Software size measurement continues to be a contentious issue within the software industry. While the software engineering community has made significant progress in it’s quest for the right way to assign value, the journey has not been without missteps and detours. And there is still more work to be done.
When I first started programming it never occurred to me to think about the size of the software I was developing. This was true for several reasons. First of all, back in the day, software had a tactile quality through the deck of punched cards required to run a program. If I wanted to size the software I could touch, feel or eyeball the deck to get a sense of how much there was. Secondly, I had no real reason to care how much code I was writing; I just kept writing until I got the desired results and then I moved on to the next challenge. Finally, as an engineering student I was expected to learn how to program but I was never taught to appreciate the fact that developing software was an engineering discipline. The idea of size being a characteristic of software was foreign to me – what did it really mean and what was the context? And why would anyone care?
Twenty five years later, if you Google the phrase “software size” you will get more than one hundred thousand hits. Clearly there is a reason to care about software size and there are lots of people out there worrying about it. And still I am left to wonder – what does it really mean and what is the context? And why would anyone care?
It turns out there are several very good reasons for wanting to measure software size. Software size is an important component of productivity and quality metrics. The ability to measure productivity and quality are an important part of any process improvement initiative. The ability to measure size is essential to successful software project estimation. Additionally, a good software size measure could conceivably lead to a better understanding of the value being delivered by a software application. The problem is that there is no agreement among professionals as to the right units for measuring software or the right way to measure within the units we use today. Read more about Software Measurement.