Moving Slow to Move Fast

This is a parable aimed squarely at bosses of software development teams.

Zone 2

I made the decision to start running long distances when my son was born about 15 years ago. It was a workout I could do without driving anywhere and a workout that I felt like packed a lot of fitness into a relatively short time frame. I didn’t know what I was doing when I started other than doing what came naturally. If I wanted to go faster, I just ran faster and it sucked more. But I never got fast, nor did the longer distances get any easier over the course of 15 years of running.

Finally I decided to actually learn how to go about training distance from people that have seen success. One of the most outstanding changes I’ve made to my running is spending a lot of time in “Zone 2”, the second of 5 heart rate ranges from 1 to 5, going low to high. Experiments have shown that spending 80% or more of your training time in Zone 2 yields real results in tests of endurance.

Zone 2 is slow. For me it’s a maximum heart rate of 138 beats per minute (bpm). To put it in perspective, when I started my journey into Zone 2, I could cruise for 10 miles at 165bpm. So it made me slow down. My runs seem to take forever. I actually have to walk sometimes just to make sure I don’t spike my heart rate. I don’t feel like I’m getting faster. But science tells me that through the discipline of going slower, my aerobic capacity is building. And that will make me faster over the long hall. Eyes on the prize.

Invest Early and Often

So how does this little parable translate to software development?

Often, when we’re working on a project, we want the instant gratification of seeing it work. Or, we find ourselves rushing to get something to market — MVP mindset, pressure from investors, bosses, etc. Neither of those instincts are wrong necessarily in and of themselves. But the long term effects of the behaviors they evoke can be devastating to a product over time.

Deciding to favor speed over quality early on in an engineering effort will ultimately grind things to a halt. Deciding to invest a little in the development version of “Zone 2” will pay off with ever-increasing speed over time. Here are 3 things that take time from feature development that you should never not do:

  • Take time to automate important processes — automated tests, coverage reporting, deployments, etc.
  • Be a stickler about test coverage.
  • Make as much code as possible reusable, or at least develop a system that makes it easy to make code reusable should it become necessary.

Sometime you have to go slow to go fast.

The Proverb

To the short-sighted, an investment seems like an expense; money out of their pocket that they can’t spend on instant gratification. A wise investment made by someone with their eyes on the horizon will pay large dividends.




Engineer, Leader, Adventurer

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

CS371p Spring 2021, 8 Mar–14 Mar

The Problem with Metrics

Why do things that do not matter matter

Multi-Container Docker with Flask, Redis & Celery

Will Kubernetes Be the End of DevOps?

How To Build a Simple Magic 8 Ball in Python

Windows Networking Troubleshooting 4: Slow Response of .NET Framework Applications

Behind Alibaba’s Double 11 Mysterious “Dragonfly” Technology ®C PB-Grade Large-File Distribution…

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
John Cox

John Cox

Engineer, Leader, Adventurer

More from Medium

The “years of experience” myth

Old man with computer.

5 Ways to Onboard New Developers, so They Don’t Feel Lost

People working

The Five-Point Framework for Saying No

The Importance of Trust in (Remote) Work