Skip to content

Edit Cycles, and the Tax of Latency

Latency compounds. That’s the whole idea. Every time you wait - for an answer, for a build, for a test to finish - you pay a small tax. Most days you don’t notice. Across a team, across a quarter, you’ve handed over a meaningful chunk of your year.

The unsettling part is the longer you’ve been somewhere, the worse you get at seeing it.

Here’s a thought exercise the early agilists liked.

You have a question. How long does it take to get an answer?

  • Same bullpen: a few seconds.
  • Down the hall: a few minutes - and let’s be honest, you might not bother.
  • Different building: longer, harder, often punted.
  • Different time zone: hours, or a full day.

Each step seems trivial in isolation. Multiply by questions per day, days per week, and people across the org, and the waste is no longer trivial.

This was the actual reason behind XP’s original same-room rule. Not aesthetics. Not vibes. Proximity is a latency optimization.

And questions are just one example. Builds. Tests. Code review. Deploys. Anywhere your team enters a loop, latency is doing math on you.

A team I consulted with did most of their testing by hand. Their loop was about as simple as it gets:

  1. Think and code.
  2. Test and verify.

So we timed it. Verification averaged 4 minutes. Think/code averaged 4.5 minutes. Total cycle: 8.5 minutes. They got through about 40 cycles a day.

Then we invested in a real unit test suite. Verification dropped to under 30 seconds. Edit cycles went to 70+ a day - close to double.

Delivery sped up. Code quality went up too - and that one was unexpected. It turned out the team had been leaving small messes behind because cleaning them up cost a 4-minute round trip per attempt. Once that tax disappeared, so did the mess.

You might be thinking: “Great, another agile sermon.” Fair. It isn’t.

The numbers are illustrative. The discipline is the point:

  • What does your team do over and over?
  • How long does each instance take?
  • What slow thing have you stopped noticing because it’s always been there?

Slow builds. Slow tests. Slow approvals. Slow environments. Slow context-switches between four tools to do one job. Any of these can silently dominate a team’s week, and the team usually won’t flag it, because they’ve adapted around it.

This is one of the most concrete ways to honor Time Doesn’t Wait For You: shorten the cycles you live inside. Everything downstream gets cheaper.