People grasp for ways to understand & communicate the fundamental complexity of a software project. As a programmer it’s particularly hard to communicate to non-technical people how big and complex a piece of software is.
The most common metric is LoC – Lines of Code. It’s a simple metric: How many lines of code did it take to create a particular piece of software? For non-programmers this is a pretty good metric. It gives them something to nod their heads at in meetings. For programmers this isn’t a very good metric at all. As with any prose, lines of code can vary in utility, complexity, and meaning.
Programmers would like to be able to gauge size and complexity in a more meangingful way. Other metrics are offered from time to time. The number of classes. The number of endpoints on a service. The number of possible execution paths. Many possibilities exist. Automated tools start to crop up.
All of these measurements are fine if they give some insight into a project. But there’s this missing piece that never seems to figure in: People.
In particular, how many people have touched the code?
This is an unavoidably fuzzy metric. Each person’s impact on the code is unpredictable on its own. What is undeniable is that a 50k line application with a 3 programmer history is a totally different beast than a 50k line application with a 15 programmer history.
Tallied up, perhaps the number of people who worked on a codebase can give us an added dimension to consider.