The Typical Project Over Time: A Long-Term Trends Report
What does a typical software project look like, and how has what’s “typical” changed over time? To find out, we segmented QSM’s database of more than 10,000 completed IT projects and looked at several software development metrics for each ten-year time period.
During the 1980s, the typical software project in our database delivered 154 percent more new and modified code, took 52 percent longer, and used 58 percent more effort than today’s projects. Figure 1 captures these changes.
Below, we’ve summarized how the key elements of a software project lifecycle have changed from 1980 to the present.
Scope: A major shift in the way projects are managed is in the basic view of what constitutes a project. It’s entirely possible that systems aren’t shrinking as fast as industry software size metrics would indicate. It may be, instead, that it is the view of what makes up a project—a manageable unit of work that is tracked and charged as a separate entity—that has gotten smaller. In a very real sense, we may just be working smarter, not harder, breaking large, complicated projects into smaller, less complex projects that humans can manage and adapt to in an increasingly technical environment.
Schedule: Project schedules have decreased dramatically from a high of almost eighteen months in the 1980s to ten to eleven months after the year 2000.
Effort: Average person hours per person month for analysis through build and test started off high in the 1980s but decreased through the 2000s before increasing slightly from 2010 to the present. Overall, the trend is toward projects expending less effort in the analysis through build and test phases.
Size: From the 1980s to the present, average new and modified delivered code volume was reduced by about 65 percent. Most likely projects are smaller due to new lifecycle methodologies, such as agile, which promote allocating smaller groups of features to a predefined timebox, sprint, or iteration. Also, programming languages are becoming more powerful, which allows each line of code to create more functionality.
Team size: Average team size changed only slightly since the 1980s, dropping by only half a full-time-equivalent person. We suspect the influence of project size reduction has been offset by increases to architectural and algorithmic complexity. While smaller systems generally require fewer developers, technical complexity tends to increase the demand for team members with specialized skills and diverse subject matter expertise.
Primary language: For projects put into production during the 1980s and 1990s, COBOL was the dominant programming language. In the 2000s, Java eclipsed COBOL and has continued to be the most frequently used primary language. People are often surprised at the enduring presence of COBOL, but the majority of recent COBOL projects in our database represent maintenance releases of existing systems rather than new developments.
Reuse: The percentage of reused code has continued to decline to about 35 percent for projects completed between 2005 and 2010. Integrating existing frameworks and legacy code with newly written code is a significant complexity factor that can have dramatically different effects on project productivity.
Both our 2006 and 2010 research studies showed steady improvement in most IT effectiveness measures over time. Projects have continued to become more compact, expend fewer resources, and take less time to complete even as they become more complex and the teams building them grow more diverse and distributed. Is there some natural limit beyond which further attempts to reduce the size, effort, and schedules of what we call a project become counterproductive? We’re looking forward to seeing how these trends change (or stay the same) as we get more data.
