Tag: technical debt

I watched a team spend a year building an event-sourced order system. By year two, half the events were no longer relevant to the business, the audit log had become write-only because nobody trusted its integrity, and they were maintaining a dozen projections just to keep the lights on. Three years after launch, they rewrote the whole thing as a boring CRUD app with a simple changelog table—and shipped it in three months. They shipped it in three months.

The architect who championed event sourcing had moved on by then. The team that remained ate the cost.

The story is familiar to software teams everywhere: we invest in complex systems and DevOps tools that promise scalability but deliver more moving parts to maintain.

Chris Kiehl wrote about this exact dynamic—not event sourcing per se, but the broader pattern. He built an event-sourced system, discovered it was harder than expected, and had the honesty to say so publicly. Most people don’t. They just quietly maintain the complexity they chose.

His closing question cuts through all the noise:

“For which core problem is event sourcing the solution? If you can’t answer that concretely, don’t do it.”

If the answer is vague—”auditability,” “flexibility,” “it seems cool”—a simple history table solves 80% of the value with 5% of the complexity.

Why This Keeps Happening to Software Teams

The pattern isn’t unique to event sourcing. It’s everywhere. A prestigious architectural pattern or project management platform gets championed by someone influential. It is smart—in the right context. But the context gets lost. Teams adopt it because “everyone uses it,” or because it seems like the forward-thinking choice. By the time they realize it doesn’t fit their workflow, they’re already committed.

And incentives are misaligned. The advocate gets credit for being visionary. The maintenance team pays the long-term cost. That asymmetry keeps complex software ecosystems alive even when they’re clearly failing.

And here’s the uncomfortable part: the incentives are misaligned. The person who advocated for the new pattern gets credit for being visionary. The team maintaining it four years later bears the cost. This asymmetry is why prestigious patterns persist even when they’re clearly failing.

The same thing happens with tools. A startup uses Jira because it scales. A mid-market company uses it because the startup did. A mature team uses it because “everyone uses it”—and by then, they’re stuck. They’ve built workflows around its constraints. Migrating looks catastrophic. So they stay, paying the integration tax: tracking deployment progress in Jenkins, planning in Jira, code review in GitHub, and spending 40 minutes a day context-switching between them.

It’s the classic DevOps platform sprawl problem—teams juggling five “integrated” tools to do the work one well-connected systemcould handle.

They know it’s inefficient. But the alternative feels riskier than staying put.

What Actually Matters

Before you commit to something that constrains your future—whether it’s an architectural pattern, a tool, or a whole platform—ask these questions honestly:

• What problem does this solve, concretely? Not theoretically. Concretely. If you can’t articulate it in a sentence without hand-waving, you’re probably not solving it.
• Are we buying capability or bloat? Does it integrate cleanly with the rest of our stack, or are we buying integration complexity along with it?
• Who pays if we’re wrong? If it’s not the people who championed it, that’s a red flag.

These aren’t flashy questions. They won’t make you sound forward-thinking in a meeting. But they’re the difference between a choice that scales with your business and a choice that becomes technical debt. These questions apply as much to software collaboration tools as to architecture choices.

Try This Instead

• Start with the smallest thing that works. CRUD + a changelog/history table first. Add sophistication only when a real constraint shows up.
• Time-box experiments. If the promised benefits aren’t visible within a fixed window, roll back.
• Write the de-adoption plan before adoption. “How would we back out of this in three months?” If you can’t answer, don’t start.
• Make incentives symmetrical. The champion should own maintenance outcomes for at least one cycle.

When your DevOps and project management tools evolve with your team instead of ahead of it, you stay fast—and stay sane.

---

Read Kiehl’s full post.—it’s honest, well-reasoned, and exactly the kind of writing we need more of online: admitting when the cool thing wasn’t the right thing.

Ready to simplify your stack? See why teams are moving away from Jira, GitHub, GitLab, and Atlassian to a unified platform. Or try GForge free for up to 5 users.