DEV Community

HotfixHero
HotfixHero

Posted on

Why “Works on My Machine” Should Be a Jira Status

There are two constants in software development:

  1. Deadlines that make no sense
  2. The phrase “works on my machine”

If you’ve been in the trenches long enough, you’ve heard it. Maybe you’ve even said it (shame on you). It’s the universal excuse, the verbal shrug that says “I washed my hands of this problem. May the production gods be with you.”

It’s the tech equivalent of this AAA story I once heard:
A driver in a 2017 Volkswagen Golf GTI calls in, panicked, because his car died on the roadside. The AAA agent, sitting in the office, casually replies: “That’s weird… I’m looking out the window right now and I see the exact same car drive by just fine.”
See the problem? That other car isn’t his car. Just like your laptop isn’t production.

And yet, “works on my machine” keeps haunting us. Why should we keep pretending? Let’s make it official: a Jira status.

Imagine the workflow:

  • To Do
  • In Progress
  • In Review
  • Works on My Machine
  • Blocked
  • Done

Because honestly, half of the time, that’s where tickets live anyway.

Here’s what “Works on My Machine” really means:

  • Dev Environments Are Snowflakes Everyone’s running a slightly different version of Node, Java, Docker, or whatever fresh hell your stack requires. Your laptop is not production—it’s a theme park simulation of production, with fewer rides and more exceptions.
  • We Treat CI/CD as a Suggestion If every commit doesn’t go through the same build and deploy pipeline, congrats—you’re running a volunteer fire department for bugs.
  • No One Owns Infrastructure Developers blame Ops. Ops blames developers. QA just cries quietly in the corner. Meanwhile, the business wonders why the “simple fix” took three days and a therapy session.

But here’s the kicker: the business doesn’t care if it works on your machine. They care if it works in production, for actual paying users, without setting fire to servers like it’s Guy Fawkes Night.

So yes, let’s add “Works on My Machine” as a Jira status. At least then, we’d have an honest reflection of the mess. Transparency is the first step toward fixing it.

Or—and here’s a crazy thought—we could stop treating DevOps as a luxury.
Same environments, same pipelines, automated tests that run where it actually matters. Radical, right?

Until then, I’ll keep clicking refresh on Jira tickets stuck in limbo, whispering: “Fly free, little bug. May you one day work somewhere else.”

Top comments (1)

Collapse
 
jonlauridsen profile image
Jon Lauridsen

"Same environments, same pipelines" has been the prescription since the twelve-factor app wrote it down in 2011. Fifteen years, and we still ship the excuse instead. That's the part worth staring at: not that the gap exists, but that we stopped experiencing it as a problem.

There's a name for that: learned helplessness. Take enough shocks you can't control and you stop reaching for the lever, even after someone unlocks it. Staging, canaries, ephemeral environments, testing in production. Each one was locally rational. Together they're a budget line for weather.

I'd add one thing to your Jira status: it never gets assigned. Devs own their code, ops own the cluster, and the difference between a laptop and production is in nobody's job description. Some of it is genuinely irreducible, live state and topology were never going to fit on a laptop. But versions, config, permissions and dependencies aren't weather. Those we picked.