Engineering Metrics: The Git Spark Story

When "Objective Data" Leads You Astray

After writing about measuring AI's contribution to code, I was frustrated. I couldn't quantify how much AI tools were actually helping my development process. Git history seemed like the obvious answer—objective, comprehensive, and already being tracked. Every commit, every change, every contributor permanently recorded. Surely, I could extract meaningful insights from this data, right?

Wrong. Very wrong. That weekend, instead of just analyzing Git data, I decided to build something better. I wanted to create a tool that could honestly report what Git history actually contains—without the misleading "health scores" and fake productivity metrics that plague existing tools. This became git-spark, my first npm package.

I thought building the tool would give me answers. Instead, it taught me about all the questions Git history simply cannot answer. But that journey—from frustrated developer to package publisher—revealed something more valuable: the fundamental limitations of measuring software development through commit logs.

This is the real story of creating git-spark: a weekend project born from frustration, shaped by AI tools, refined through trial and error, and ultimately designed to admit what it doesn't know. If you're trying to measure developer productivity or AI contributions through Git data, here's what I learned about what you can and cannot reliably discover.

Building Git Spark: My First npm Package

That weekend, I decided to build what I wished existed: an honest Git analytics tool. Having used npm packages for years, I'd always wanted to create my own. Git-spark became that opportunity—and my crash course in package development.

The AI tools I used (ironically, the same ones I was trying to measure) gave me an impressive initial implementation. The code worked, the visualizations looked professional, and the metrics seemed authoritative. That's when I made a critical mistake: I actually read the formulas behind the numbers.

This realization forced multiple rewrites. Each iteration stripped away another layer of pretense, another attempt to derive meaning from data that simply didn't contain it. By version 0.5, I'd removed every evaluative metric and replaced them with honest observations.

The Problem with Current Metrics

The most popular Git-based metrics aren't just unhelpful—they're actively harmful. They measure motion instead of progress and incentivize behaviors that damage both code quality and team culture.

I learned this lesson the hard way. Within a month of introducing commit-based metrics, our most disciplined engineer—someone who routinely made comprehensive, well-tested commits— appeared to be our least productive. Meanwhile, a junior developer who committed after every minor change topped the charts. The metrics were giving us exactly the wrong signal.

What Git History Cannot Tell You

Building git-spark taught me something humbling: the most valuable aspects of software development leave absolutely no trace in commit logs. This was my biggest surprise and the most important lesson from the entire project.

I started this journey trying to answer one specific question: "How much of my code is generated by AI prompts?" After weeks of analysis, creating formulas, and examining every metric Git history offers, I have to admit defeat. Git simply doesn't—and cannot—record that information.

This realization completely changed how I thought about developer productivity measurement. Every existing tool I'd examined—the ones claiming to measure "health" or "productivity"—suffered from the same fundamental flaw: they measured motion, not value. They counted commits but ignored impact.

Building Honest Metrics

Here's where I started to understand what Git analytics could legitimately provide. The problem wasn't using Git data—it was pretending it measured things it didn't. "Repository health" is marketing speak. "Activity patterns" is honest reporting.

Many tools generate "health scores" or "productivity ratings" that sound authoritative but are fundamentally subjective. They take the limited data Git provides, apply arbitrary weights and thresholds, then package it as objective truth.

This shift from evaluation to observation is crucial. We're not saying the team is productive or unproductive. We're saying "here are the patterns we observe; you decide what they mean for your context."

Team Patterns in Code

This is where Git analytics gets genuinely interesting: not for measuring individual productivity, but for revealing patterns that would otherwise remain invisible. Your code structure mirrors your team structure, and Git history exposes that relationship.

Conway's Law states that organizations build systems that mirror their communication structure. Git analytics makes this visible through patterns that emerge from how developers interact with the codebase. These patterns don't tell you if your team is "good" or "bad"—they tell you how your team actually works, which is far more valuable.

I discovered this accidentally when analyzing why certain features always took longer than estimated. Git analytics revealed that three supposedly independent modules had high co-change coupling—they couldn't be modified independently in practice, even though the architecture said they could. This explained why every "simple" change rippled through the system.

What Git Spark Does

Despite failing to measure AI contributions, I succeeded in creating something useful: an honest Git analytics tool that respects what the data can and cannot tell us. This became git-spark, my first npm package.

Git-spark doesn't tell you whether your repository is "healthy" or your team is "productive." Instead, it shows you patterns and lets you interpret them with your domain knowledge.

# Install globally
npm install -g git-spark

# Or use with npx
npx git-spark analyze

Lessons Learned

I set out to answer a simple question: "How much of my code is generated by AI prompts?" I built an entire analytics tool, published my first npm package, and learned more about Git internals than I ever expected. And I still can't answer that question.

But that failure taught me something more valuable: the discipline of honest measurement. Not every question has a data-driven answer. Not every metric is meaningful. And tools that claim to measure everything often measure nothing reliably.

Git-spark doesn't tell you if your team is productive. It doesn't measure code quality. It can't identify AI-generated code. What it does is report observable patterns in your repository's history and then—crucially—shuts up. No fake scores. No pretend insights. Just data and the humility to admit its limitations.

Building git-spark taught me that the best metrics tools don't pretend to have all the answers. They provide honest data and trust you to ask better questions. That's the philosophy behind every line of code in git-spark, and I hope it's useful to others wrestling with these same measurement challenges.