The Five-Day Sprint That Should Have Been Four Hours
Or: How We Stopped Using CI as a Debugging Tool and Learned to Love Data
Remember Egg? Let me tell you about Egg. He’s one of our engineers here at Agoda, and his story is one you’ve probably lived yourself. Day one of standup: “Small change to a backend API. Should be done by end of day.” Day five of standup: Task finally complete, Egg exhausted, manager frustrated, and everyone wondering how a four-hour task turned into a week-long odyssey.
If this sounds familiar, congratulations — you’re experiencing what GitHub’s research tells us is the norm, not the exception. According to their data, it takes 2–3 days just to merge code at most tech companies. That’s not development time; that’s just the bureaucratic machinery grinding away after you’ve written your code.
As Maya Angelou once said, “We delight in the beauty of the butterfly, but rarely admit the changes it has gone through to achieve that beauty.” In our case, we’re so focused on the beautiful features we ship that we ignore the painful metamorphosis our engineers endure just to get their code running locally.
The Problem Nobody Wants to Discuss
Let’s return to Egg’s story because it’s really our story — all of us who’ve scaled from that one perfect team where everything just worked to the sprawling technical metropolis where nothing quite fits together anymore.
Egg spent his first day trying to debug and get the backend API working on his laptop. There was a Confluence page, of course. There’s always a Confluence page. Steps upon steps, tweaking JVM settings, using Docker containers, commenting out parts of the sbt file. By day four, Egg had given up on local development entirely. His new development loop? Push to Git, wait 20–40 minutes for CI to run, get feedback, repeat.
The economist John Kenneth Galbraith once observed about financial speculation: “The euphoria is followed by the crash, and the crash is followed by recrimination.” In Egg’s case, the euphoria of “just one more push should fix it” was followed by the crash of another failed build, and the recrimination from stakeholders wondering why such a simple change was taking so long.
The Inner and Outer Loops of Developer Experience
Developer Experience breaks down into two critical loops:
The Inner Loop — everything before you commit. This is your local development: debugging, testing, building. It’s supposed to be fast, iterative, immediate. When it works well, you’re in flow. When it doesn’t, you’re Egg on day four.
The Outer Loop — everything after you commit. CI pipelines, code reviews, deployments. This is where process meets technology, and where most organizations focus their optimization efforts while ignoring the foundation crumbling beneath.
Think of it like training for a marathon. The inner loop is your daily training runs — they need to be sustainable, repeatable, even enjoyable. The outer loop is race day. You can’t fix bad training with a perfect race strategy.
The F5 Experience: When Local Development Actually Works (But Slowly)
Now, Egg’s situation was extreme — his local environment was completely broken. But what about the teams whose local environments work, just… slowly?
We started measuring what we call the “F5 Experience” at Agoda. Press F5 (or Shift + F9 for Intelij) in your IDE to start debugging, and how long until you have a browser open with your application actually loaded and interactive? This isn’t about CI; this is about your local development cycle when everything is supposedly “working.”
What we found was sobering. Some of our systems took up to 24 minutes from pressing F5 to seeing a page load. Twenty-four minutes! That’s not a development environment; that’s a coffee break with a side of email checking.
At 20% productivity loss for context switching between two tasks (according to research from Quality Software Management), those coffee-break compile times aren’t just annoying — they’re expensive.
When CI Becomes Your Debugger: The Egg Syndrome
Here’s where Egg’s story diverges from the slow-but-functional scenario. When we looked at the data for Egg’s team, we saw something telling: no local development metrics at all. Zero. Nothing. Why? Because Egg couldn’t get his local environment working.
This is the uncomfortable truth we need to confront: when your local development environment becomes so painful that pushing to CI for feedback seems reasonable, you’ve already lost. You’re not just losing developer time; you’re losing developer joy, engagement, and ultimately if this keeps up long term, retention.
Measuring What Matters (Or: Google Analytics for Developers)
We built something you could call “Google Analytics for Developers” — open-source collectors that capture real data about the developer experience. Not surveys, not estimates, but actual metrics: compile times, startup times, test execution times. We’re capturing about 20,000 build events per day across local development and CI.
The data revealed patterns we suspected but couldn’t prove. Systems with 1–2 minute startup times showed developers opening browsers 2–3 minutes after web server startup — clear evidence of context switching. But systems with 20-second startup times? The gap dropped to 5–20 seconds. Developers stayed engaged, stayed in flow. So even a few minutes in startup time can cost you in your developer effectiveness.
The Bottom Line: Your CI Is Not a Debugger
If your engineers are using CI as their primary feedback mechanism, you’re not just wasting time — you’re hemorrhaging money and talent. Every 20-minute CI cycle that could have been a 20-second local build is a developer contemplating whether the grass might be greener at that startup down the street while he makes his 4th coffee of the day.
The solution isn’t revolutionary: measure your inner loop, identify the pain points, and systematically eliminate them. Use tools like our open-source build metrics collectors (check them out links below). Make local development so smooth that pushing to CI without local validation becomes as socially unacceptable as deploying on Friday afternoon.
JavaScript Ecosystem (Webpack, jest, vite, vitest, rspack)
GitHub - agoda-com/devfeedback-js *Contribute to agoda-com/devfeedback-js development by creating an account on GitHub.*github.comdotnet (msbuild, dotnet cli, nunit, xunit)
GitHub - agoda-com/dotnet-build-metrics: Measure Compilation time of Dev local C# projects *Measure Compilation time of Dev local C# projects. Contribute to agoda-com/dotnet-build-metrics development by creating…*github.comJVM (scalatest, junit)
GitHub - agoda-com/java-local-metrics *Contribute to agoda-com/java-local-metrics development by creating an account on GitHub.*github.comThe next time someone tells you that developer experience improvements aren’t a business priority, remind them of this: we’re not asking for luxury. We’re asking for the basic tools to do our jobs without wanting to throw our laptops out the window. In software development, as in life, you can ignore the elephant in the room, but eventually, it’s going to step on something important.
Now, if you’ll excuse me, I need to go help another team discover that their 30-minute build could actually take 3 minutes if we just… but that’s a story for another post.
Want to measure your own developer experience? Check out Agoda’s open-source build metrics tools. leave your dev experiance stories in teh commetns below.