Moving Slow to Move Fast
This is a parable aimed squarely at bosses of software development teams.
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.
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.