Why lines of code and commit counts fail as productivity metrics
Both are easy to collect, which is the only argument for them. Here is what each one actually rewards, and what to record them as instead of what they are usually sold as.
Lines of code and commit counts correlate weakly with delivered value and strongly with habits that are easy to fake. Neither belongs in a productivity score. Both are legitimate operational signals — code churn and change frequency — when you stop asking them to answer a question they were never built to answer.
Lines of code has been a punchline in software engineering for decades, and commit counts have quietly taken its place in dashboards that would never admit to using the older metric. The appeal of both is the same: they come free from tools you already run, they produce a number instantly, and that number goes up and to the right often enough to look like progress.
The trouble is that going up and to the right is exactly what makes a metric dangerous once anyone knows it is being watched. A metric a team can move without changing the outcome it is meant to represent is not measuring that outcome. It is measuring how well the team has learned to move the metric.
What lines of code actually rewards
A count of lines added rewards verbosity over compression, and duplication over reuse. The engineer who copies a twelve-line function into three call sites and edits each copy slightly will out-score the one who extracts a shared four-line helper, even though the second engineer left the codebase in better shape. Refactoring — deleting duplicated or dead code to make a system smaller and safer — actively hurts this metric, which means the metric is actively opposed to work you want more of.
It also cannot distinguish a hard problem solved in twenty lines from an easy one solved in two hundred, which means it systematically undervalues the engineers who are good at finding the small fix and overvalues the ones who reach for the large one.
What commit counts actually rewards
Commit count has a gentler failure mode but the same shape. It rewards chopping one unit of work into many small commits over doing the same work in one clean commit with a coherent message. Teams that adopt strict trunk-based development with frequent small commits as a genuine engineering discipline will show high counts for good reasons; teams that have simply noticed the dashboard will show high counts for bad ones, and from the outside the two are indistinguishable.
If a metric can be satisfied by changing how you format work rather than what work you do, it will eventually be satisfied that way. Not out of dishonesty — out of the ordinary human response to being watched.
The tell: these metrics move independent of outcomes
The fastest way to see the problem is to hold the metric next to something that actually matters and watch them decouple.
| Metric | What moves it | What it misses entirely |
|---|---|---|
| Lines of code | Verbosity, duplication, large-diff habits | Whether the work was needed, or delivered on time |
| Commit count | How finely work is chopped into commits | Whether any commit fixed a real problem |
| Tickets closed | Ticket size and how tickets are split | Whether the closed ticket stays closed |
None of these rows is an argument for ignoring the underlying data. Commit history and diff size are genuinely useful when read as engineering signals rather than performance signals — a sudden spike in churn on a file is worth a look, a commit with no message and an 800-line diff is worth a look. The failure is specifically in attaching a person's name and a ranking to them.
Keep them, but as signals not scores
What to measure instead
The honest alternative is slower to set up and harder to fake, which is precisely why it works: a small number of weighted factors — productive time approved by a manager, on-time completion, estimate accuracy and reviewed quality — that pull against each other enough that gaming one costs you another. None of it comes free from a version-control API, but all of it answers the question lines of code and commit counts were only ever a proxy for.
If your organisation is currently reporting either metric on an individual scorecard, the cheapest fix available today is to stop, and replace it with nothing rather than with a worse substitute, until you have the approved-hours model in place.
Goalz never counts commits or lines of code. Every score is built from approved hours, on-time completion, estimate accuracy and reviewed quality — bring a sprint and we will show you the difference on real data.