Speed vs Velocity in Software Engineering

Everyone loves a good saying, right? When I got my driver's license, my mother would often bless me with this one:

Rather arrive 20 minutes too late, than 20 years too early.

Back then, while still a kid, I'd just smile and shrug it off. Nowadays, as a slightly older kid, I find myself recalling it quite often while working on various product and engineering tasks.

When we look at the IT landscape, it would seem that being fast is the only thing that matters. Faster time to market, faster release cycles, faster response to demand fluctuations, faster pivoting, faster this and that. Going any faster and, per Einstein, we might just go back in time instead of forward, which is what 2020 feels like.

A plethora of processes and tech was devised around being able to deliver stuff faster. We have Scrum, Cloud, DevOps, the ability to work remotely, open floor office plans, and I will even throw in JS frameworks. Those are just some examples of good and less good things trying to make us become faster.

But what does fast mean? How do we measure fast? In which timespan do we measure it and what do we measure it against?

Physics defines speed as a scalar value and velocity as a vector. This means that velocity has direction. It channels speed somewhere, and with that, it gives effectiveness to speed. Without direction, you are just running in place, aimlessly.

I have seen many software engineers and teams that have great speed but, over a fixed course of time, they would do 20 steps forward and 10 steps back. A total of 30 steps made for only 10 steps of progress. A huge waste of time and energy.

Would not it make more sense to only do 10 steps forward in the same amount of time?

My favorite manifestations of valuing speed without understanding velocity would probably be:

• Coding tutorials and academies spitting out coders in weeks.
• Never-ending release stream of code faster and more easily frameworks.
• Magical software abstractions promising one-click whatever-features.

Similarly to how hacking is portrayed by Hollywood, software engineering is a tad more complicated than what you can see in every other technology showcase video. While focusing on speed is tempting, we need velocity to achieve quality. That means moving with less speed, but in the right direction.

In software engineering, this translates to:

• Think first, code later. Validate your thoughts in the meantime.
• Do not abuse patterns. Bad domain design does not get better with a fancy pattern.
• Comments, comments, and some more comments.
• Do not reinvent the wheel, but do not use a square one either.
• Rather release 2 days later than spend 2 days firefighting.

Going back to the physics reference, applying velocity over a fixed amount of time will produce a covered distance. Between velocity, distance, and amount of time, you can only modify two and let the third parameter balance itself out.

In software, the distance would be the product you are building. If you want the same product built in less time, you need to increase velocity. At that point, a common theme is to start sacrificing quality to achieve speed. This results in an increased amount of steps back, which ultimately reduces velocity.

Understanding the difference between speed and velocity is what makes a coder an engineer.