Module activity_metrics 

Activity Metrics and Their Limits

Activity, the A in SPACE (chapter 3.1), counts the volume of engineering work observable from system telemetry: commits, pull requests opened, lines of code changed. It is the easiest SPACE dimension to measure, because every one of these events is already logged automatically — and that ease of measurement is exactly what makes this dimension the most dangerous one to over-weight. Activity measures motion, not value: a commit count does not distinguish between a commit that solved a hard problem elegantly and a commit that split one meaningful change into five to look more productive.

Formula

Commit substitution gaming signal =
    commit_count rose AND average_commit_size shrank

Activity rate = commits / engineers / weeks
    (a contextual signal only, never a standalone productivity proxy)

Why it matters

This is the single most historically misused metric family in software engineering measurement. Once activity becomes an incentivized individual metric, gaming follows almost immediately: padding commits, splitting changes trivially, avoiding deep, unglamorous work that produces few visible events. This module exists to detect that specific gaming pattern and to compute an aggregate rate for context — never to rank or score an individual. Commit count, lines of code, and pull request count should never appear in an individual performance review, a comparative ranking, or any context where an engineer’s compensation, standing, or reputation depends on the number.

Example

use software_engineering::activity_metrics::{
    is_commit_substitution_gaming_signal, commits_per_engineer_per_week,
};

// A team's commit count rose 40% while average commit size fell by
// more than half — meaningful changes were likely split into many
// trivial ones to inflate the count.
assert!(is_commit_substitution_gaming_signal(50.0, 70.0, 120.0, 50.0));

// Both count and size rising together is ordinary growth, not gaming.
assert!(!is_commit_substitution_gaming_signal(50.0, 70.0, 120.0, 140.0));

// Read only in aggregate, alongside the other SPACE dimensions —
// never as a standalone verdict on any one person or team.
let rate = commits_per_engineer_per_week(120.0, 6.0, 4.0).unwrap();
assert!((rate - 5.0).abs() < 1e-9);

Pitfalls

• Ranking or evaluating individuals by raw activity counts — the single hardest, most important rule this chapter states; the moment activity becomes an incentivized individual metric, gaming follows almost immediately.
• Reading an activity number in isolation — a sharp drop in team-level commit activity alongside a rise in satisfaction might mean the team finally had breathing room to pay down technical debt, a positive pattern that looks alarming without that context.
• Treating raw volume as a quality-adjacent signal — prefer size relative to review depth, or the ratio of new code to code removed, over a bare count.
• Missing the substitution-gaming pattern — rising frequency alongside sharply falling change size is the clearest sign activity is being inflated rather than genuinely increasing.

Sources

• Chapter 3.4, Activity metrics and their limits.

Topic doc: software-engineering-metrics/locales/en-001/chapters/03-04-activity-metrics-and-their-limits.md

Functions

commits_per_engineer_per_week

Commits per engineer per week — a simple activity rate, provided only as a contextual signal to read alongside the other SPACE dimensions, never as a standalone productivity proxy or an individual ranking.

is_commit_substitution_gaming_signal

Whether a change in commit count and average commit size matches the chapter’s named substitution-gaming pattern: splitting genuinely meaningful work into many small, trivial commits to inflate a count.