Is Project Size Shrinking? A Long-Term Trends Report
QSM recently completed a study, utilizing its project database of more than 10,000 completed projects, that analyzed how and why project size has changed over time. The latest data shows that the long-term trend toward smaller, more compact projects has continued since last measured in 2006. In the early 1980s, the average size of a software project was approximately 85,000 new and modified source lines of code (SLOC). By the early 2000s, this number had decreased to about 28,000 SLOC.
While the average is a useful measure of central tendency, it can be influenced by very large or very small values in the sample. The median values (half of the data above and half below) shown in figure 1 demonstrate the trend toward smaller projects even more clearly. In the early 1980s, the median new and modified code delivered was four times larger than median project sizes for systems completed after the year 2000.
Figure 1
Why Are Projects “Shrinking” Over Time?
This size reduction most likely reflects a combination of factors:
More efficient and powerful programming languages and methods: As technologies and development environments continue to evolve, each line of code delivers more “bang for the buck” per line in terms of functionality.
New lifecycle methodologies: Methodslike agile, RUP, and incremental builds attempt to manage scope creep by allotting smaller groups of features to predefined timeboxes, sprints, or iterations.
Measurement inefficiency: Well-established and defined sizing techniques, like function points, require trained practitioners and can be expensive to count. Plus, they don’t always capture all the work required to deliver the product. Organizations like IFPUG are developing techniques like SNAP3 to account for this kind of nonfunctional work. Early, design-based size measures, like requirements, stories, and use cases, may be defined at toohigh a level to fully capture scope creep as the design evolves. As sizing techniques used in the industry become more refined, we’ll be interested to see if the long-term trend toward size reduction continues.
Significant use of unmodified code: Whether it takes the form of frameworks, reused or legacy code from existing applications, or generated code, reuse continues to represent a significant portion of delivered applications. Since figure 1 reflects only new and modified code delivered during each time period, reuse is not reflected.
In figure 2, we delved more deeply into code reuse. We divided our sample into ten-year time buckets. The solid black line represents the average percentage of reused (unmodified) code. The percentage of reused code has declined steadily, from about 50 percent reused code, on average, for the 1980s to about 45 percent reused code in the 1990s and about 35 percent in the 2000s.
Figure 2
This decline in reuse may well reflect the realization that integrating existing frameworks and legacy code with newly written code is a significant complexity factor that can—depending on how well it is implemented—have dramatically different impacts on project productivity.
It’s entirely possible that systems, per se, aren’t shrinking as fast as industry software size metrics would indicate. It may be, instead, that the uptick in agile and RUP projects are changing the way we view a project, and that the predefined timeboxes, sprints or iterations are seen as projects in their own right. We may just be working smarter, not harder: breaking large, complicated systems into smaller, less complex, easier-to-handle projects that are more manageable in an increasingly technical environment.
The definition of a project is still evolving, and QSM will continue to study patterns related to project size and productivity in future research projects.
