Faster or Slower?

Speed kills. Measure twice, cut once. Rework Avoidance Theory. We’re trained from an early age to slow down when faced with uncertainty. To be cautious. To not drive faster than we can see. And often it’s true. Especially when operating heavy equipment. Simple physics tells us that mass * velocity equals inertia. And as Newton said, an object in motion stays in motion. Changing directions or stopping means working against that inertia. So if you want to be agile and be able to change your direction easily then you need to slow down.

So what do we do in software development to make sure we don’t go too fast and make it hard to change direction? A common response is to add process. Long manual processes to ensure that we keep going in the correct direction. That we’re not wasting our time. That nothing bad happens. Cascading gates with lots of places to stop and roll back. That makes sure we’re going slow for safety. Right?

That’s one option for sure, but it’s not the only one. And in many cases, with software it’s not the best option either. Slowing down reduces inertia for sure, but it’s not the only way. Consider the other half of the equation. Reducing the velocity by 50% reduces inertia by 50%. But the same thing happens if you reduce mass. It’s a linear equation, so you can have just as much impact by changing mass.

In development the analog to mass is the size of the change. Smaller changes are less “massive”, so for a given velocity they have less inertia. They have less coupling. They have less surface area. They have less drag. They take less time. They’re easier to undo. So you can make more changes.

There’s another thing to keep in mind. When you slow down changes tend to accumulate, so the “mass” goes up. In fact, it’s not unusual for the mass to go up so much that going slower means there’s even more inertia and it’s even harder to make changes. Which is exactly the opposite of what you want.

Or, as I’ve said before, Speed is Life