Quantifying the Invisible: Understanding 'Dark Matter' in Engineering Impact Scores

Dark Matter: The Invisible Gravity

Machu introduces the concept of Dark Matter in code universes to explain the stability provided by work that never appears in Git commits. The Engineering Impact Score (EIS) tool reveals that high-stability teams rely on ‘Anchors’ whose primary contributions are invisible to commit-based tracking. This invisible work includes code reviews and design discussions that prevent structural decay.

Why This Matters

Metrics that rely solely on Git commits fail to observe the ‘dark matter’ of software development—the essential non-commit activities like mentoring and architectural planning. Ignoring this invisible mass leads to the misidentification of ‘Anchor’ engineers as low-performers, potentially destabilizing the very systems that hold a codebase together. Technical leadership must account for these ‘gravitational effects’ to avoid optimizing for visible output while neglecting the structural integrity provided by invisible labor.

Key Insights

• The ‘Anchor’ role, identified via the Engineering Impact Score (EIS), provides team stability through non-production work that often bypasses commit logs.
• Code reviews act as an ‘Observer Effect’ in software physics, changing the universe by deleting or improving code without generating new commits.
• Design discussions, such as a 30-minute whiteboard session, determine the structure of thousands of lines of code despite being unrecorded in Git history.
• Small refactors, like a 3-line rename or 5-line method extraction, function as a force against entropy to prevent long-term structural decay.
• The Engineering Impact Score (EIS) tool, available via Homebrew as machuz/tap/eis, specifically measures the ‘gravitational effect’ of invisible work rather than the work itself.

Working Examples

Installation command for the Engineering Impact Score (EIS) CLI tool.

brew tap machuz/tap && brew install eis

Practical Applications

• Use Case: Identifying ‘Anchors’ in a team using EIS to ensure stability-focused engineers are recognized despite low commit volume. Pitfall: Judging productivity solely by commit numbers, which leads to the loss of engineers who prevent system crumbling.
• Use Case: Implementing structured code reviews to observe and change code structure without bloating commit history. Pitfall: Treating small refactors as ‘noise’ in logs, which accelerates technical entropy and structural decay.

References:

• https://dev.to/machuz/git-archaeology-10-dark-matter-the-invisible-gravity-45ne