15 min readJust now

–

A completely true story about measuring the unmeasurable, until it measured us back.

Chapter 1: The Reasonable Beginning

It started innocently enough. Q4 planning meeting. Stockholm, 2024.

“We need better metrics,” the CTO said, which is what CTOs say when they don’t know what’s wrong but know something is.

I proposed something simple: track not just what we ship, but what we don’t ship. Abandoned branches. Stashed code. The builds that developers cancel after seeing the queue. Basic shadow work analysis.

Everyone nodded. Made sense. Very reasonable.

I built the first version over a weekend. Called it Spegling — Swedish for “reflection.” It counted abandoned branches and graphed them against sprint velocity. Simple. Harmless.

The correlation was -0.73. For every abandoned branch, our velocity dropped by roughly 0.4 story points. We were literally measuring our own hesitation.

“Interesting,” the CTO said. “What else can we measure?”

Chapter 2: The Depth Finder

Week two. I added the AI Baseline Comparison — measuring how far human code deviated from what GPT-5 would write with minimal simplicity tilted prompting.

Junior developers averaged 2.3 units of deviation. Senior developers averaged 8.7 units. Made sense… experience manifests as complexity, right?

But then there was Sven from the platform team. 0.9 units. Less deviation than juniors. His code was simpler than what simplified AI would write.

Press enter or click to view image in full size

“Sven, your code is… basic.”

“Yes.”

“But you’re a staff engineer.”

“Yes.”

“For fifteen years.”

“Yes.”

I pulled his commit history. Sven had the highest bug-fix rate, fastest feature delivery, lowest incident count. His code just… worked. Always. Boringly. Perfectly.

Chapter 3: The Shadow Economy

Month two. We expanded shadow tracking. Not just abandoned branches, but uncommitted files, local changes, even clipboard history (with permission, mostly).

The numbers were staggering:

• 3.7 shadow branches per merged PR
• 47% of code written never left developers’ machines
• $2.1 million of features built but not shipped

We started the Shadow Recovery Project. Simple idea: review abandoned branches, maybe merge the good ones.

First recovery: Emma’s three-month-old stash contained the exact feature our biggest client just requested. Already built. Already tested (locally). Just… forgotten.

Second recovery: A junior developer’s abandoned branch from his first week contained a fix for our memory leak. He’d thought he was doing it wrong because it was too simple.

The ROI was immediate. We were mining our own forgotten gold.

Chapter 4: The Complexity Compass

Month three. I added trauma detection. The system identified “defensive code patterns” and traced them to specific incidents using commit messages and comments.

Our authentication service was a masterpiece of paranoia:

• Seven different timeout strategies (The Friday Deploy Disaster)
• Triple redundant caching (The Redis Apocalypse)
• Checksums for checksums (The Bit Flip of 2019)

Björn’s code defended against events that were statistically impossible. His functions had more safety checks than actual logic.

Meanwhile, Sven’s auth code was twelve lines. No defensive patterns. No trauma markers.

“Aren’t you worried about edge cases?”

“They’re not edges if you stay in the middle.”

I didn’t understand what that meant. The metrics didn’t either. Sven’s code remained stubbornly, suspiciously simple.

Chapter 5: The Intention Tracker

Month four. Added micro-probes. Tiny prompts when developers did something interesting:

When someone wrote complex error handling:

“What failure haunts this function?”

When someone stashed code:

“What would make you ship this?”

The responses revealed hidden architecture:

• “Jenkins ate my weekend again”
• “Waiting for Kubernetes to not be cursed”
• “This works but I don’t know why”

Sven never answered the prompts. Not once. The system started flagging him as “non-compliant.”

“Sven, why don’t you answer the development insights prompts?”

“Busy.”

“Doing what?”

“Working.”

His velocity remained constant. A flat line across all metrics. No peaks, no valleys. Just… delivery.

Chapter 6: The Echo Chamber

Month five. Spegling now tracked “echo patterns” — similar solutions appearing across the codebase without coordination.

We found seventeen different implementations of the same distributed lock pattern. Nobody had documented it. They’d all just… arrived there.

The visualization was beautiful. Ideas spreading through code review like viruses, mutating slightly with each host, becoming more refined or more paranoid depending on the developer’s trauma index.

But Sven’s code showed no echo patterns. He didn’t copy others. Others didn’t copy him. His code existed in a bubble, untouched by organizational consciousness.

“Don’t you look at other people’s code?”

“Sometimes.”

“Don’t you learn from it?”

“No.”

“Why not?”

“It’s their code.”

Chapter 7: The Productivity Paradox

Month six. I added sentiment analysis on code structure itself. Aggressive nested loops indicated frustration. Elegant recursion suggested joy. Excessive try-catches revealed anxiety.

The heat map was disturbing. Tuesdays were red with rage. Thursday afternoons glowed with resignation. There was a perfect circle of happiness around the coffee machine’s IP address.

Sven’s code was emotionally neutral. Not just calm — absent of emotion. Like code written by someone who didn’t know feelings existed.

Meanwhile, the emotion patterns were contagious among everyone else. If one developer wrote angry code, the next three commits would also read as frustrated.

We had a whole episode where Marcus wrote such frustrated code that it infected the entire microservices cluster with what we called “digital depression.” Build times increased 40% out of what I can only describe as algorithmic sadness.

Chapter 8: The Dream Journal

Month seven. Peak strangeness begins. Code written between 11 PM and 4 AM had different patterns. More recursive. More elegant. Sometimes impossibly elegant.

Emma’s 2 AM sorting algorithm violated O(n log n) bounds but worked. Nobody could explain why. (Sven was not asked.)

Johan’s midnight refactor used variable names in what appeared to be ancient Sumerian.

The entire infrastructure team collectively invented the same cache invalidation strategy on the same night, despite working from different home offices.

Sven didn’t code at night.

“I sleep,” he said.

“But what about when inspiration strikes?”

“It doesn’t.”

His commits clustered between 9:30 and 10:07 AM, 2:30 and 3:04 PM. Like clockwork. Like someone pretending to be human but not quite getting the timing right.

Chapter 9: The Collective Unconscious

Month eight. The patterns were undeniable. Our codebase had developed its own intelligence — not AI, but CI. Collective Intelligence.

Functions appeared that nobody remembered writing (even Git blame did tell who). reconcile_state_drift() existed in seven services, evolved and adapted, like it had written itself through us.

The visualization looked organic. A neural network of human decisions, each developer a neuron firing in a larger brain.

Except Sven. He was a dead zone in the heat map. A black hole where patterns went to die.

“Sven, this function everyone’s using — “

“Which one?”

“reconcile_state_drift()“

“Never heard of it.”

“It’s everywhere.”

“Not in my code.”

He was right. His services just… didn’t drift. They stayed reconciled through what I can only describe as aggressive simplicity.

Chapter 10: The Recognition Engine

Month nine. Spegling started recognizing individual developers by their code style alone. Deep psychological profiles from syntax.

Press enter or click to view image in full size

“Johan is going through personal stress. His null checks have increased 340%.”

Johan was going through a divorce.

“Sara’s code shows patterns consistent with major life change.”

Sara announced her pregnancy the next week.

“Marcus is planning to quit. His documentation completeness has spiked — he’s preparing handover.”

Marcus gave notice two days later.

But for Sven: “UNABLE TO PROCESS. PATTERN UNRECOGNIZABLE.”

The AI actually seemed frustrated. It kept trying to categorize him:

• “Possibly deceased?”
• “Bot account?”
• “Quantum superposition of developer states?”

Chapter 11: The Sven Singularity

Month ten. I became obsessed with Sven. His metrics made no sense:

• Complexity: Lower than junior developers
• Productivity: Higher than senior developers
• Bug rate: Approaching zero
• Shadow branches: Zero
• Emotional fingerprint: None
• Echo patterns: None
• Trauma markers: None

“Sven, what’s your secret?”

“No secret.”

“But your code — “

“Works.”

“But HOW?”

“I write what needs to be written.”

I studied his PRs. Every function did exactly one thing. Every variable had exactly one purpose. No abstractions “for future use.” No clever optimizations. No defensive programming.

It was like he’d solved software development and hadn’t bothered to tell anyone.

Chapter 12: The Investigation

Month eleven. I pulled Sven’s entire history. Fifteen years of commits. The pattern was consistent from day one:

• Never more than 50 lines per function
• Never more than 3 parameters
• Never nested beyond 2 levels
• Never used a design pattern

The senior architects were horrified.

“No patterns? No SOLID principles?”

“Those are for problems,” Sven said. “I don’t write problems.”

I ran his code through every analyzer we had. It broke them. Not because it was bad, but because it was too simple to analyze. Like trying to find the meaning in a perfect circle.

His code had achieved something beyond optimization: irreducibility. Every line necessary, no line superfluous.

Chapter 13: The Shadow Discovery

Month twelve. The revelation came from the Shadow Pipeline itself.

Everyone else had massive shadow branches: abandoned ideas, failed experiments, complexity that grew in darkness.

Sven had none. But not because he didn’t experiment. Deep in the Git reflog, I found it: thousands of micro-commits, each one slightly simpler than the last. He wasn’t avoiding complexity — he was collapsing it.

Every night at exactly 11:47 PM, automated commits. Refactoring. Simplifying. Removing one line, one parameter, one condition at a time.

“Sven, these nighttime commits — “

“What commits?”

“The simplification runs.”

“I’m asleep by ten.”

I checked the security logs. He was telling the truth. Then I checked the commit signatures. Same SSH key. Same machine. Laptop was online, committing code.

“Sven, is your laptop doing this on its own?”

“It learned.”

He’d trained a local model on his commit patterns. Not to write code , but to delete it. The model’s only job: find what could be removed while tests still passed.

“You automated simplification?”

“It’s the only task worth automating.”

The model was 97KB. Smaller than most React components.

Even his AI was aggressively simple.

Chapter 14: The Tool Emerges

Month thirteen. We rebuilt Spegling around what we called “The Sven Principle.”

Instead of measuring complexity, we measured distance from simplicity. Instead of tracking what developers added, we tracked what they could remove.

New metrics:

• Simplification Potential: How much could be deleted while preserving function
• Complexity Debt: The gap between current and minimal implementation
• The Sven Distance: How far from Sven-like simplicity

The results were humbling. Our codebase was 73% unnecessary. Not wrong, not broken — just unnecessary.

Chapter 15: The AI Rebellion

Month fourteen. We integrated GPT-5 to suggest simplifications. It lasted three hours before having what I can only describe as an existential crisis.

“This code makes no sense. It works but it shouldn’t. It’s too simple. Where are the edge cases? Where are the abstractions? WHERE ARE THE DESIGN PATTERNS?”

It started adding complexity to Sven’s code, trying to “fix” it. Every suggestion made it worse. The AI was literally having a breakdown trying to understand how something so simple could be so effective.

Press enter or click to view image in full size

Final error message before we shut it down: “SVEN IS IMPOSSIBLE. SVEN VIOLATES BEST PRACTICES. SVEN SHOULD NOT WORK BUT DOES. WHAT IS SVEN?”

Chapter 16: The Measurement Recursion

Month fifteen. Spegling became self-aware. Not in a sci-fi way — it just started measuring itself.

It found its own complexity debt. Started refactoring itself. Removing features. Simplifying dashboards.

The beautiful visualizations collapsed into simple text:

• “Code: Working”
• “Bugs: 3”
• “Sven Distance: Far”

“What happened to the 3D graphs?” the CTO asked.

“Unnecessary,” Spegling responded.

It had learned from Sven. Or Sven had infected it. Or maybe Sven was it.

Chapter 17: The Truth

Month sixteen. Annual review time. The metrics were clear:

Sven had:

• Lowest complexity scores (should be fired)
• No innovation indicators (should be fired)
• No collaboration patterns (should be fired)
• Highest delivery rate (should be promoted)
• Zero production incidents (should be promoted)
• Perfect customer satisfaction (should be promoted)

“We can’t promote him,” HR said. “He fails every metric except the ones that matter.”

“Maybe,” I suggested, “we’re measuring the wrong things.”

The dashboard agreed: “METRICS ARE UNNECESSARY COMPLEXITY.”

Chapter 18: The Organization Transforms

Month seventeen. We implemented the Sven Protocol:

1. Write what needs to be written
2. Remove everything else
3. Go to sleep at reasonable hours

Productivity increased 400%. Not because we worked harder, but because we stopped doing unnecessary work.

The Shadow Pipeline emptied. Not because we shipped the abandoned code, but because we stopped abandoning it. We stopped writing it in the first place.

Bugs decreased 90%. Not because we got better at finding them, but because simple code has fewer places for bugs to hide.

Chapter 19: The Customer Paradox

Month eighteen. Something disturbing happened. Sven started “fixing” customer problems.

Not by asking customers what they wanted. Not by analyzing user data. He just… fixed things.

“Sven, the customer wants a dashboard with — “

“No they don’t.”

“They specifically requested — “

“They want their data. Dashboard is complexity.”

He replaced our entire analytics platform with a CSV export.

Customer satisfaction increased 200%.

“But they asked for real-time visualizations!”

“They asked wrong.”

I pulled the support tickets. Customers were downloading the CSV, then uploading it to… another dashboard tool. Then exporting it again. Then emailing it.

Sven watched this for one day.

Next morning, the CSV export was gone. Replaced with an email button.

“It just emails them the numbers they actually look at.”

“What numbers?”

“Same three every time. Revenue, users, errors. Nobody reads the rest.”

Customer satisfaction increased another 100%.

“But what about — “

“They forward the email to Excel anyway.”

He’d discovered the dark secret of enterprise analytics: every dashboard ends as an email with three numbers in it.

We’d built a $50M visualization platform to delay the inevitable spreadsheet by 45 seconds.

Chapter 20: The Business Simplification

Month nineteen. Sven was promoted to product owner. His first act: delete the product roadmap.

“What about our five-year vision?”

“Too far.”

“Three-year?”

“Still too far.”

“One year?”

“Next week is far enough.”

He started shipping features before customers asked for them. Not by predicting needs — by removing the obstacles they didn’t know they had.

Our subscription management system? Replaced with “Cancel anytime” button. No forms. No surveys. Just cancel.

Churn dropped 60%.

“But we need to know WHY they’re leaving!”

“They’re not leaving anymore.”

Chapter 21: The Marketing Incident

Month twenty. Sven attended his first marketing meeting.

“We need to communicate our value proposition through multiple touchpoints across the customer journey — “

“No.”

“But how will customers understand our product?”

“They use it.”

“But before they use it?”

“They don’t need it yet.”

Marketing was furious. They went rogue, launched a campaign without Sven’s approval: “Revolutionary AI-Powered Enterprise Solutions for Digital Transformation.”

It worked. Sales increased 400%.

For a completely different reason than marketed.

Chapter 22: The Truth About Marketing

Month twenty-one. We discovered why the marketing campaign worked.

Customers weren’t buying “AI-Powered Enterprise Solutions.” They were buying because our checkout process was now one click. Sven had simplified it while marketing was making presentations.

But marketing claimed victory. They started measuring everything:

• Click-through rates on emails nobody read
• Engagement on social posts nobody saw
• Attribution models for sales that would have happened anyway

“Marketing drove $50M in pipeline!” they announced.

Sven’s response: “Pipeline is not revenue.”

The dashboard agreed: “97% OF MARKETING METRICS ARE MEASURING NOTHING.”

Chapter 23: The Zero-Line Codebase

Month twenty-two. The inevitable happened.

Sven discovered our entire product was solving a problem that didn’t need to exist.

“What if,” he said, during a normal Tuesday standup, “we don’t?”

“Don’t what?”

“Any of this.”

He’d realized our entire B2B SaaS platform — all 2.3 million lines of code — was essentially moving data from one place to another place where it was slightly easier to read.

“We could just… teach them SQL.”

The room went silent.

“That’s a terrible idea,” the CEO said.

“Yes,” Sven agreed. “But also true.”

Chapter 24: The Marketing Salvation

Month twenty-three. Sven had reduced our codebase by 94%. The product barely existed. It was beautiful in its simplicity and completely unsellable.

Marketing panicked. Then they did something brilliant.

They didn’t pivot the narrative. They inverted the entire category.

“What if,” the CMO said, “we charged for what we removed?”

The pitch became: “Complexity Reduction as a Service.”

Enterprises didn’t buy our three features. They bought our methodology. The Sven Protocol became a consulting engagement. We’d audit their codebase, measure their Complexity Debt, calculate their Sven Distance, then charge $500K to delete 70% of their code.

The positioning was surgical:

• “Your competitors are drowning in technical debt. You’re paying for ours to be removed.”
• “We deleted 2.1 million lines of code. Your audit starts at line one.”
• “Every feature we remove increases your valuation by $2M.”

The product itself? A loss leader. The CSV importer, SQL box, and Share button were just proof we’d survived our own simplification.

But the service — helping enterprises measure and eliminate their own unnecessary complexity — that became the moat.

Gartner didn’t create a quadrant for us. We convinced them to deprecate three entire categories as “solved by radical simplification.”

The tagline that closed deals: “We’re expensive because we make you smaller.”

Price: $500,000 audit + $50,000/month to keep you honest.

Revenue model: We get paid more the less you build.

Chapter 25: The Market Response

The first enterprise deal closed in 11 minutes.

Not because they understood the product. Because their CTO saw our codebase metrics dashboard and said: “If you can do this to yourselves, you can do it to us.”

Within a quarter:

• Three Fortune 500s paid us to delete their features
• Two unicorn startups hired us to “un-scale” their architecture
• One major bank brought Sven in to simplify their trading platform (he removed 40 microservices, replaced them with a cron job)

The analyst coverage was strange:

“They’ve weaponized minimalism.”

“Negative feature velocity as a competitive advantage.”

“First company to successfully charge for subtraction.”

Competitors panicked differently than expected. They didn’t copy us — they couldn’t. Adding a “simplify” button to complex software just made it more complex.

Instead, they started hiding. Burying features in submenus. Calling bloat “enterprise-grade.” Rebranding technical debt as “battle-tested architecture.”

We became the threat they warned their boards about: “If we’re not careful, we’ll get Sven’d.”

The market had found its new fear: being exposed as unnecessarily complex.

And we’d learned to charge for the exposure.

Chapter 26: The Ultimate Measurement

Month twenty-four. Final board meeting of the year.

“Revenue is up 1,200%,” the CFO announced.

“Our codebase is down 97%,” I added.

“Customer satisfaction is 94%,” the head of success reported.

“Marketing attribution shows — “ marketing started.

“Unnecessary,” Sven interrupted.

The board looked at our final metric dashboard. It had one number:

Profit.

Below it, in small text: “Everything else is vanity metrics.”

Chapter 27: The Philosophical Crisis

Month twenty-five. The organization faced an existential crisis.

If Sven was right — if 97% of our code was unnecessary, if customers didn’t want what they asked for, if marketing sold illusions that happened to work — what were we actually doing?

“We’re a story company,” marketing insisted. “We sell narrative!”

“We’re a technology company,” engineering countered. “We sell solutions!”

“We’re neither,” Sven said. “We’re done.”

“Done?”

“Problem is solved. Company can close.”

The room erupted. Close a profitable company? Absurd!

“Or,” marketing suggested, “we keep selling the story that we’re solving problems.”

Chapter 28: The Infinite Loop

Month twenty-six. We discovered the ultimate truth.

Every company exists in two states:

1. The Sven State: Solving real problems with minimal complexity
2. The Market State: Creating complexity to justify existence

We needed both. Sven to keep us honest. Marketing to keep us funded.

Sven would simplify until nothing remained. Marketing would complicate until everything seemed essential. The tension between them created a sustainable business.

It was absurd. It was necessary. It was capitalism.

Chapter 29: The Product Vision

So here we are. Building Spegling. Or maybe we’re building the story of Spegling. Or maybe the story IS Spegling.

It definitely measures:

• Shadow work worth millions in unshipped code
• The Sven Distance (how far you are from dangerous simplicity)
• Complexity debt (what you could delete)
• Developer trauma encoded in defensive patterns
• The collective unconscious of your codebase
• Which problems you’re solving vs. creating

It probably tracks:

• When developers will quit (increased documentation)
• Which features customers actually use (hint: three)
• How much of your product is marketing fiction
• The exact moment your startup lost its way

It possibly detects:

• When you should shut down the company (Sven Point)
• When marketing has completely disconnected from reality
• The precise amount of complexity needed to seem valuable
• Whether your entire industry should exist

It definitely shows you the uncomfortable truth:

• Your codebase is 73% unnecessary
• Your customers want 10% of what you built
• Your metrics measure 3% of what matters
• Marketing will save you anyway

Epilogue: The Question

But here’s what I really want to know:

What would you want Spegling to measure in YOUR organization?

The exact percentage of your code that exists to impress other developers?

How many of your “critical” features have never been used?

The correlation between meeting count and actual productivity?

The shadow features that would 10x your business but are too simple to price?

How close you are to your own Sven Point: where the problem is solved and the company should theoretically close?

The gap between what marketing promises and what engineering delivers (and why it doesn’t matter)?

The precise amount of complexity you maintain just to justify your salary?

Because we’re building something. Something that measures the unmeasurable. Something that reveals the shadow work, the abandoned brilliance, the unnecessary complexity, and the beautiful simplicity hiding underneath.

Something that might tell you your entire business model is an elaborate fiction wrapped around three useful functions.

Something that definitely exists.

Unless Sven deletes it for being unnecessary.

Which he probably will.

Press enter or click to view image in full size