Speed Limits in Software Development

I took the train into Toronto last weekend and without my car spent the weekend walking everywhere. As I walked under the highway, I was struck by how obsessed we are with speed. I could hear the thump, thump of car tires as they rushed by over my head at 100+ km/hr (traffic was good for once). As a species we have gone from being able to move at the speed our legs could carry us, to using animals to help us move faster and then eventually we started using mechanical devices like the bicycle to increase our speed. With the invention of mechanical engines we’ve added even more speed. Our cars will rush us from place to place in almost the blink of an eye. We can listen to an audio book about a pioneer family taking months to cross a part of America and we can’t even finish the audio book before all the country they covered has all rushed passed the windows of our car. What used to take months, now takes hours.

But even with all that speed, there are limits on how fast we can go. Jump on a jet plane and you can get across a country or continent pretty quickly, but it still takes time. Physics still applies. I could wax philosophical on our obsession with speed and what we loose from it – and I may yet do that at some point – but in this article I want to move us into thinking about the limits of speed in software development. It is an axiom of modern software development that faster is better, and like I said that is a philosophical discussion for another day, but how fast can we actually go? What are the limits of software development? The speed a developer can type? I don’t think anyone is advocating instantaneous deployment on each keystroke a developer does. If not that, then perhaps the limit is how fast we can get a minimum viable feature completed. By how do we know if it is viable?

You might be able to guess that I am going to argue that quality matters. What is the fastest we can move in software development? That is, of course, not quite the right question. How fast a can a car go? Well, if it is an F1 race car, pretty fast. If it is a car attempting to set a land speed record, even faster. But those things aren’t really what we are asking about. For the vast majority of us, the answer to how fast a car can go has to do with the posted speed limit and not with the physical limits of our car. Someone engaged in a police chase can go pretty fast, but it certainly wouldn’t be safe to do so. When we are trying to figure out how fast we can go in software development we aren’t trying to figure out they physical limits of it (deploy on every keystroke). We are trying to find how fast we can safely deploy.

For software development there aren’t road signs telling us a safe speed to deploy at, but perhaps we can extend the driving metaphor a bit more to help us think this through. One thing that relates to safe speed is responsiveness. A slick road makes it harder for your car to respond to changes in direction, and slow deployment makes it hard to respond to problems with your application. How easy is it to respond to issue in your application? Don’t forget that an F1 race car with new tires and perfect tuning can respond a lot better than the little commuter car you might have. We can tune our code and deployments and get better at responsiveness over time.

If the road is foggy and you can’t see where you are going when you drive, I hope you slow down. If you can’t see what is going in your application and understand how it is being used, I hope you slow down.

Let’s think a little more about the foggy road analogy though. Sometimes we think of testers as fog lights. We pierce the darkness a bit and show where there might be threats. That is helpful when we are stuck in the fog, but in software we have an option that we don’t have in car driving. We can dispel the fog. We can make our applications more observable. Fog lights are helpful but sunshine is even better.

So how fast can we go in software development? Well, in the ideal case if we know everything and have a smooth path ahead of us, pretty fast. I don’t think we can get to a land speed record since software development doesn’t often involve going in a straight line, but with a bit of work on the code and deployment process and with investment in observability and operations, I think we can go pretty fast, pretty safely. Just be careful. Don’t try to drive your homemade hot rod as if it is an F1 race car. Go fast and push the limits, but know where those limits are for your situations (and then make them better).

Photo by Adrien CÉSARD on Unsplash