Avoid Metric Anti-Patterns — Engineering Metrics & DORA, Part 7

Engineering Metrics & DORA · Part 7

Every bad engineering metric shares one flaw: it measures activity that's easy to count instead of the outcome you actually want — and the moment you reward it, people optimize the number and let the real thing rot. This walks through the classic offenders — lines of code, commits per day, velocity, coverage percentage — why each one backfires, and the outcome-based questions to ask instead.

"When a measure becomes a target, it ceases to be a good measure." Goodhart's Law. Almost every metric trap.

Before you start

• Your current dashboard, or whatever the team is actually measured on — including anything that appears in a performance review. The anti-patterns below are not hypothetical; the exercise is finding which ones you already have.

• Willingness to remove a metric. This tutorial is subtractive, and removing a number someone senior likes is the hard part.

• The delivery metrics from Parts 1-5 in place, or at least started. "Stop measuring this" is a much easier argument when you can point at what you measure instead.

• Fifteen minutes with someone who is measured by these numbers rather than someone who reads them. They can tell you how the metric is already being gamed, and they usually will if asked plainly.

Step 1: Lines of Code Per Engineer (10 min)

"Sarah wrote 5000 lines last quarter; Bob wrote 1000."

Bob refactored 4000 lines down to 200. More valuable.

LOC measures volume, not value.

Don't measure engineers by LOC. Don't display it. Don't reference it.

Step 2: Commits Per Day (10 min)

Many small commits ≠ productive.

Some engineers:

• Big logical commits

• Small WIP commits

• Squash before merge

All work. Counting commits punishes one style.

If counting at all: team-level trends only.

Step 3: Bug Count (10 min)

"Sarah closed 50 bugs; Bob closed 5."

Bob fixed 5 hard bugs. Sarah closed 50 trivial typos.

Closed-bug count rewards triage, not impact.

Track: severity-weighted, time-to-close, customer impact. Not bare count.

Step 4: Meetings as Activity (10 min)

"Manager attended 30 meetings this week."

Means: 30 meetings.

Not productive output. Reduce meetings if possible.

Don't optimize for time-in-meetings.

Step 5: Story Points / Velocity (15 min)

"Team velocity: 50 points → 70 points → goal: 100"

Tempting. Backfires:

• Engineers inflate estimates

• Easy work prioritized over impactful

• Stress to "hit velocity"

Velocity is your team's estimating + working speed. Internal planning aid, not a target.

Don't compare velocities across teams. Don't grow it as a goal.

Step 6: Test Coverage Percentage (10 min)

100% test coverage doesn't mean good tests. Doesn't mean fewer bugs.

def test_func():
    func()  # called; no assertion; 100% coverage

Coverage as a gate (80% min for new code): OK signal.

Coverage as a goal: optimized via garbage tests.

Step 7: Sprint Closing Rate (10 min)

"95% of stories closed in the sprint."

Engineers:

• Pad estimates

• Avoid risky work

• Cut corners to close

Healthy: ~80% closing rate; spillover expected; learn from it.

100% closing = no ambition or fudged numbers.

Step 8: PR Throughput Per Engineer (10 min)

"Sarah merges 10 PRs/week; Bob merges 3."

Bob: one PR was a 500-line architectural change.

Sarah: 10 typo fixes.

Don't rank by PR count.

Step 9: The Antidote: Outcomes (10 min)

Better than activity metrics:

• Did we ship the feature?

• Are customers happier?

• Are we hitting SLOs?

• Are engineers staying / growing?

Outcomes are harder to measure. But aligned with business reality.

A team shipping few-but-impactful features beats a team shipping many trivial ones.

Step 10: When Metrics Help (10 min)

Metrics help when:

• Used at team / system level

• Tracked over time (trend > snapshot)

• Inform decisions (not punish individuals)

• Paired with qualitative input

Metrics hurt when:

• Used as individual evaluation

• Used as targets for growth

• Used in isolation (no context)

• Used without trust

The intent matters. Same metric: tool or weapon.

What each anti-pattern actually rewards

Every metric here is a proxy that got promoted to a target. None is useless as context; all are damaging as a score, because people optimise what they are judged on and every one of these is easier to game than to earn.

Metric	What it looks like it measures	What it actually rewards	Use instead
Lines of code	Productivity	Verbosity, copy-paste, and never deleting anything. Refactoring shows as negative output	Whether the change achieved its outcome
Commits per day	Activity	Splitting work into meaningless commits. The history gets worse, not better	Nothing. This is context at best
Bug count	Quality	Not filing bugs, or arguing about severity instead of fixing them	Change failure rate and recovery time, at team level
Meeting hours	Collaboration	Attending, not contributing. Punishes the async written culture you want	Whether people can get unblocked — ask them
Story points / velocity	Delivery rate	Point inflation. Velocity is a planning aid that means nothing across teams and drifts within one	Lead time, which is measured in hours rather than in a currency the team mints
Test coverage %	Test quality	Tests that execute code without asserting anything. 100% coverage with no assertions is achievable and worthless	Coverage as a floor on new code, plus mutation testing if you want to know whether tests catch anything
Sprint closing rate	Predictability	Sandbagging estimates and closing tickets that are not done	Whether the thing shipped and worked
PR throughput per engineer	Individual output	Small safe changes, avoided hard work, and gaming that scales with how visible the metric is	Team-level flow. Per-person delivery metrics are the anti-pattern, not a variant of it

You're done when

• You can name every metric currently used to evaluate an individual engineer, and you have a plan to remove or relabel each one.

• For each metric you keep, you can say what behaviour it rewards when someone is optimising for it deliberately — because someone will be.

• You have asked one engineer how they would make a given number look good without doing better work, and you got a real answer. If they cannot think of one, the metric may be sound; more often they answer immediately.

What You Just Did

Metric anti-patterns: LOC, commits, bugs, meetings, velocity, coverage, sprint close, PRs, outcomes-instead, when metrics help. Avoid the traps.

Common Failure Modes

Engineer-level metrics for performance. Gaming; resentment.

Velocity as goal. Inflated estimates; quality drops.

Test coverage as goal. Garbage tests.

Sprint closing as goal. Padding.

Metric without context. Misleading.

---

Sources

• DORA, DORA's software delivery performance metrics — current definitions and the five-metric set.

• DORA, Research — the State of DevOps report archive. Band thresholds sit inside individual annual reports and differ by year; quote the year with the band.

• References & Sources — the version caveats that apply across everything on this site.

Continue the Engineering Metrics & DORA path

• Previous — Part 6: The SPACE Framework

• Next — Part 8: Build a Team Dashboard

Part of the Engineering Metrics & DORA learning path.