Keywords: Lines of Code | Large Projects | Software Metrics
Abstract: This article examines the actual performance of developer lines of code (LOC) per day in large software projects, based on the "10 lines/developer/day" metric from The Mythical Man-Month. Analyzing Q&A data, it highlights that LOC heavily depends on project phase: initial stages show high LOC, while large mature projects see a significant drop to around 12 lines due to complex integration, certification requirements, and code maintenance. The article emphasizes the limitations of LOC as a metric, advocating for a holistic assessment including code quality, complexity, and design simplification, and references Dijkstra's view of treating code lines as "spent" rather than "produced."
Impact of Project Phase on Lines of Code
In software engineering, lines of code (LOC) are often used as a metric for developer productivity. However, this measure shows significant phase-dependent variation in large projects. Based on observations from the Q&A data, during the initial stages of a new project, developers might contribute hundreds of lines per day, driven by creative work and relatively simple code structures. For instance, some developers mentioned easily exceeding the 10 lines/day benchmark when starting small projects.
Real-World Challenges in Large Projects
As projects scale to millions of lines of code, with stringent certification requirements and multi-system interfaces, LOC drops sharply to around 12 lines/developer/day. This decline is not due to developer incompetence but reflects the inherent complexity of large projects. Developers spend most of their time understanding existing codebases, managing dependencies, testing, and maintaining code, rather than solely writing new lines. The Q&A notes that in large projects with certification needs, developers only work on project code part-time, further reducing LOC.
Limitations of Lines of Code as a Metric
LOC has fundamental flaws as a productivity indicator. First, it ignores code quality: concise, efficient solutions may reduce LOC while improving system performance. As stated in the Q&A, some developers pride themselves on a "negative line count," achieved by refactoring to simplify complex designs. Second, LOC fails to capture coupling, cohesion, and complexity, which are more critical software quality metrics. Quoting Dijkstra, code lines should be viewed as "spent" rather than "produced," emphasizing the importance of optimized design.
Case Studies: From High to Negative LOC
Real project data further illustrates the diversity of LOC. For example, in tutorial example development, LOC can reach 200 lines/day, but such code is highly repetitive and structurally simple. In contrast, client projects show wide fluctuations: from 20 lines/day (maintaining existing code) to -6,000 lines/day (replacing legacy systems via compilers). The latter, replacing 1.6 million lines of C++/Mathematica with 160kLOC of F#, significantly cuts maintenance costs, embodying the "less is more" engineering philosophy.
Comprehensive Metrics and Best Practices
Based on this analysis, LOC should not be used as a standalone performance metric. Developers should focus on:
1. Code quality: Reducing LOC through eliminating redundancy and optimizing design, not blindly increasing it.
2. Phase adaptability: Acknowledging that LOC naturally declines with project maturity, avoiding unrealistic expectations.
3. Alternative metrics: Combining code reviews, defect rates, and user satisfaction for a holistic productivity assessment.
In practice, as per the Q&A, developers in large projects prioritize code functionality and reliability over line count. Ultimately, the goal of software engineering is to deliver efficient, maintainable solutions, with LOC serving merely as a reference point in this process.