Measuring is for students

Managers seem to be obsessed with measuring stuff. Man-days, story points, KPI’s… It’s their way of quantifying a chaotic process in the hope of controlling it. It’s an understandable but misguided approach.

It’s what we learn at PRINCE2 school. You break a project up in small blocks. That gives you a complete scope and a spreadsheet to play with. Planning and managing become a numbers game.

Alas, this Project Management 101 is a bad preparation for the real world.

When it comes to software development, it’s very difficult to quantify the things that really matter. How do you measure quality, for example? You can’t measure it directly and so you start making up secondary metrics.

The number of bugs is often used as a QA metric. By that standard, the front-end library I once wrote is a superior product to React. Not a single bug was reported!

Issues per customer, then? Twitter must be a horrible product compared to my DIY invoicing tool.

The number of users? Defects per line of code? Defects per number of users per line of code?

It’s impossible to set a scientific metric on such a subjective thing as quality. Yet like Potter Stewart’s definition of obscenity: I know it when I see it.

Quality. Scope. Productivity. Completeness. Developers can give you a subjective view, but quantifying is impossible.

Yet these are the things managers obsess about. Why is that? Why is it that difficult to see that the team is delivering quality at a good pace?

When I was learning to drive a car, I asked stupid questions: When do you activate your indicators? 10 meters before you turn right? 5 meters? My instructor gave the most infuriating answer: it doesn’t matter.

When you don’t know how to drive, you treat it like a recipe. Release one pedal, press the other one. Look in the right-side mirror and then in the central one. You make a step-by-step plan. But that’s not the way driving works. If it was a recipe, autonomous vehicles would have been mainstream in the nineties.

Driving is a game of detecting, communicating, anticipating and deciding. That’s why my questions didn’t matter: there is no right answer. When someone is tailgating you, you start blinking earlier than on an empty street. That’s a no-brainer for those who know how to drive. If you don’t understand the game, however, quantifiable metrics are all you have.

So, back to manager metrics. How many days are in a Story Point? It doesn’t matter. What is the Definition of Done? When it’s good enough to ship.

Most managers don’t know how to deliver software. They have a recipe in mind, though.

When you are in the Shu-phase, you’ll look for clear instructions. Hard metrics. Rules. A step-by-step plan. We measure the things we don’t understand. That’s perfect for learning, but at a certain point, the training wheels have to come off.

Measuring is for students. Delivering is for masters.


Building software is hard, but don't let that stop you.

If you're building a product and feel like you could use a supportive techie in your corner, let's set up a quick chat to see if I can help you.