Stability & Speed

With software development, there’s a spectrum out there with stability on one end and speed on the other. You can have an ultra-stable system that progresses incredibly slowly, or you can iterate blindingly fast on a system that’s a mess. Skip documentation. Cram endless external dependencies into your app. Avoid writing automated tests. You can cut corners all day.

Or, at least, that’s how it looks at a superficial level. Stability, however, can be its own form of speed. Fewer external dependencies means fewer conflicts and maintenance issues. Better documentation means faster on-boarding. Automated tests mean faster bug fixes and less time spent on manual testing. At some point, the technical debt can bring progress to a halt. At that point, the tradeoffs won’t feel worth it any longer.

Of the teams I’ve been around, the easiest way to classify and understand their priorities is how they balance stability and speed. Many teams are so blindingly focused on speed in the here and now, they end up being slower in the long-run. Or, they make quick decisions, but not necessarily good decisions.

Of course, the opposite is true of teams that have a blind faith in stability. The easiest path to stability is to never change. Just maintain. Fading into irrelevance isn’t a great long-term move either though.

So maybe we should focus on stability for the sake of speed. That is, what types of tasks related to stability improve speed and reduce distractions?

It’s an easy question to ask but a difficult one to answer because it’s different for every team. Stability for stability’s sake is probably overkill. But looking at stability through the eyes of iteration and enabling forward progress provides just enough context to know where the value is.

The catch is that frequently requires experience. You have to feel the pain of the times you opted for pure speed at the cost of stability. And you likewise have to feel the pain of focusing on stability but shipping painfully slowly. Like with most things, there’s a sweet spot.

If you need a place to start, try automated testing. Regardless of your language or framework, it’s something that feels slow initially but feels liberating in the long-run. You end up writing better code with fewer bugs, thus avoiding some bugs entirely, and, when you do find a bug, it’s easier to locate and fix without regressions. With any luck, at some point you’ll be afraid to ship code without automated tests. Then the only question is how to apply all that time that’s freed up not endlessly chasing bugs.