Velocity

In the recent years one mantra above all has made its way in almost every startup, every IT company, every web agency; among every programmer, web developer, project manager, up to every company CEOs:

”Move Fast and Break Things”

This was Facebook’s motto up to some months ago (they have changed apparently) and – as in the most classic cargo cult – everybody started to adopt it as their own motto. As the right way to measure their progress towards the success.

This phenomenon was also enforced by the large-scale adoption of agile methodologies and techniques – Scrum above all – in which the velocity of a team is an essential element of self-awareness and self-control of the team itself, in order to improve the ability to estimate efforts and delivery dates.

But if you step back and look at the definition of velocity as in the Classical Physics, from a mathematical point of view “velocity” is defined as the rate of change of position with time:

In other simpler words, velocity is the ratio between two terms: space travelled divided by time elapsed. As you can see above it’s a fraction, composed by two factors: a numerator, above the line, and a denominator, below.

What all this have to do with with the software development and the IT companies? The problem I think we have is that we always consider the second factor of the equation, the time, and we forget the first one, the “space”. We stress the time it occurs to deliver something, but we don’t care (enough) of what we deliver in that time.
The only measure is the time.

Now try to remember how many times you have heard someone say, talking about a new feature, “Oh, it’s easy, it will be fast: it will just take a couple of hours (or days, whatever)” and someone else reply “Wow, you’re really fast!”. Think about how often someone came and told you “We absolutely have to deliver this new product/feature by that date”. Think how many discussion you had about the time it took to deliver a piece of software, and how this affected the perception of how “fast” you are (in one way or another).

Think about how important the idea of “velocity” has become for a startup (which makes absolutely sense, don’t get me wrong: a startup is a machine that burns money, up to the point where money ends or new fresh one is injected, and the “time to market” is a crucial factor of success; but the point I am rising here is – I repeat it again – on the upper side of the equation!)

Think about how much stress (and implicitly value) is put nowadays on a developer’s “velocity” in closing tickets, in delivering story-points, in releasing some code. I have first-hand testimony that in some company developers’ bonuses are directly proportional to the number of tickets closed. The number! No matter their complexity, no matter the correctness, efficiency and testability of the code written for that ticket. No matter the code quality or the business value delivered.

Now look again to the equation above, look at the top-right side: there is where your job is. Sorry if I’ll be rude, but if you deliver shitty code in two hours, and someone else delivers decent code in one week, you are not faster then him/her. It takes you less time, but his/her velocity is much greater than yours.

So please the next time you’ll use the word “velocity” while speaking of software development, stop for one second and think if you are not mistaking “velocity” with “time”: they are not the same.