Let‘s face it – everyone wants programmers to be productive. Managers of programmers want maximum productivity — it gets the work done faster and makes the managers look good. And programmers themselves like being productive too. It allows them to get home earlier, reduce stress during the workday, and feel better about their finished products. Even countries have an interest in programmer productivity, since it can provide a competitive advantage in the global software industry.
But here‘s the thing – the most common ways people measure programmer productivity are seriously flawed. Counting lines of code? Not a good measure. Tracking hours worked? Also problematic. These metrics miss the true essence of what software development is all about – solving problems for users.
In this article, we‘ll dig into why the traditional definitions of programmer productivity fail, and explore better approaches that focus on what really matters – delivering maximum value to customers. Let‘s get started!
Contents
Why Measuring Lines of Code Persists (Despite the Flaws)
Before we look at what‘s wrong with lines of code as a productivity measure, it‘s worth understanding why it became popular in the first place.
For managers, lines of code provides an easy, quantitative way to measure programmer output. It‘s simple to count lines of code from git commits or timesheets. And more LOC seems to correspond to getting more features done.
Programmers themselves also gravitate toward LOC because it provides a sense of concrete achievement. There‘s a feeling of satisfaction from seeing code length grow day by day. Thefortunate problem is that not all code contributes equal value.
But as we‘ll see, this simple metric fails to capture what‘s really important – the quality and impact of the software produced.
What‘s Wrong With Lines of Code
Here are a few of the main reasons using LOC as a productivity metric can be downright harmful:
- Rewards quantity over quality: More LOC incentivizes writing more code rather than better code. But more code means more complexity, bugs, and maintenance burden. Short, simple, elegant code is preferable.
- Not all code has equal value: 100 lines implementing a key algorithm creates far more value than 1000 lines for an obscure analytics feature. LOC doesn‘t distinguish importance.
- Encourages inefficiency: If one programmer needs 500 LOC to add a feature but another needs just 50 LOC, who was more productive? LOC would wrongly reward the first programmer for their verbosity.
- Discourages innovation: New technologies like machine learning can dramatically reduce LOC needed. But if programmers are rewarded for maximizing LOC, they have little incentive to adopt these better approaches.
- Easy to game: People optimize for whatever they are measured on. Developers have been known to add meaningless comments and spacing simply to inflate their LOC counts.
- Ignores big picture: Sometimes the best solution involves refactoring existing code or improving interfaces. But simplifying code reduces LOC, even when it improves the software.
LOC metrics fail because they were an easy-to-measure proxy, not because they actually assessed productivity. Let‘s look at some examples of how using lines of code as the productivity metric can lead teams astray:
- At one company, programmers were writing convoluted code to avoid modifying large legacy functions. This made the code hard to maintain, but kept the LOC metrics up.
- A game studio found programmers were splitting simple tasks across multiple functions just to increase their individual LOC counts. This created fragmentation.
- A survey by Cambridge University found ~20% of code in commercial software is dead code that is never executed. Programmers had no incentive to delete it because doing so would lower their productivity metrics.
- After transitioning to agile, one team reduced their LOC per release by 75% by avoiding duplicate code and leveraging frameworks more. But managers criticized the team for the drop in per-programmer LOC.
Measuring programmer productivity by lines of code clearly motivates the wrong behaviors. Studies suggest that every 1000 lines of code added also introduces ~15 new bugs during initial development. The more complex the code, the more errors users experience.
According to research from IBM, the average cost of fixing a bug rises exponentially the later it is caught. A bug that costs $100 to fix in design may cost over $15,000 if not caught until after launch! Complex and bloated code costs companies real money.
Better Approaches to Measuring Productivity
The key is to focus on outcomes rather than outputs. As an analogy, would you judge a chef‘s productivity by the weight of the food they produce, or by the taste and quality of the meal? Software teams should be measured by how well they satisfy users, rather than raw code output.
Here are a few ideas for measuring programmer productivity in a more meaningful way:
Customer Satisfaction – Are users happy with the software? Smooth rollouts and positive feedback indicate programmers were productive.
Business Value – Does the code deliver ROI by increasing revenue, reducing costs, or improving efficiency? Value created indicates good productivity.
Quality – Is the software reliable, secure, and maintainable? Fewer defects and technical debt is a sign of productive coding.
Innovation – Have programmers incorporated creative solutions and new techniques? Novel thinking advances productivity.
Knowledge Sharing – Do programmers document work, assist others, and share discoveries? Individual output grows from group learning.
Team Delivery – Does the team consistently ship valuable projects on time? Programming is collaborative; judging individuals by team success encourages cooperation.
Problem Solving – Can programmers adapt to changing requirements and overcome obstacles? The best developers thrive on solving the unexpected.
Automation – Have coders automated processes to reduce human effort? Automating repetitive tasks boosts productivity.
Personal Growth – Are programmers continuously improving skills and knowledge? Lifelong learning sustains productivity over the long-term.
Efficiency – Do programmers avoid duplication, leverage reuse, and minimize complexity? Efficient code increases team productivity.
Some other ideas that forward-looking managers have implemented:
- Set goals for shipping user stories rather than LOC targets. Requirements delivered is what matters.
- Measure results like uptime, performance, and response time. Outcomes matter more than outputs.
- Use peer reviews and pair programming results to gauge collaboration and team development impact.
- Factor in cross-team contributions like open source libraries, internal tools built, or documentation created.
- Reward learning. Support conference attendance, meetups, courses, and experimentation time.
- Track issues resolved end-to-end rather than hand-offs between teams. Feature delivery requires collaboration.
- Consider weighting measurement by code importance and usage. Key infrastructure code is worth more than unused tools.
Remember there is no single perfect metric that applies universally. The keys are understanding what outcomes provide the most value for your customers and business, and then setting goals and incentives that maximize those priorities.
Key Takeaways for Managers
Let‘s recap the main points for managers aiming to improve how they measure programmer productivity:
- Leverage outcome-focused metrics – Prioritize customer satisfaction, business value, and quality over output-centric metrics like story points completed or LOC.
- Incentivize the right behaviors – Ensure your metrics and incentives reinforce good engineering practices like automation, simplicity, collaboration, and technical excellence.
- Customize for your context – One size does not fit all. Tailor metrics and goals to what makes the most sense for your customers and organization.
- Take a holistic view – Consider individual contributions like mentoring, internal open source, and cross-team collaboration that benefits the broader organization.
- Measure regularly not microscopically – Some metrics may be checked quarterly rather than daily or weekly. Give programmers room rather than micro-managing.
- Engage programmers – Involve developers in defining metrics and crafting incentives they feel are fair and reward actual productivity.
Great software comes from empowered teams intrinsically motivated to deliver maximum value, not individuals chasing lines of code quotas. Rethinking how productivity and success are measured can do wonders for aligning programmers with organization goals.
The truth is, it‘s not about lines of code. It‘s about delighting customers by solving their problems. That‘s where managers should aim to guide their programmers.
Conclusion
Measuring programmer productivity by the crude metric of lines of code is flawed for many reasons. It rewards bloat, ignores value, discourages innovation, and can be gamed.
Better approaches focus on the outcomes that matter most – customer satisfaction, business value, quality, team delivery, and technical excellence. Programming is about providing solutions, not churning out code.
The most productive programmers think strategically and understand how their work fits into the big picture. They focus on simplifying code and minimizing duplication. They collaborate to build on each other‘s contributions.
Great software comes from empowered teams intrinsically motivated to maximize customer success – not isolated developers chasing arbitrary lines of code quotas. By focusing on the outcomes that truly matter, managers can help programmers sustain productivity over the long haul.
