We Don’t Out-Deliver The Competition. We Outlearn them.

I’ve long considered software development as a process of removing uncertainty.

The customer asks us for “Instagram, but for cats” – which could have infinite possible interpretations – and our job is to whittle those possibilities down to a single interpretation. Computers kind of insist on that.

How could this process be represented more essentially, so I can see the wood for the trees of such a complex thing?

Let’s play a game.

There are two teams, A and B, and they are both tasked with guessing a random 4-digit number. Their guesses must be submitted with numbers they have to carve on to stone tablets.

Team A guesses all 4 digits at a time. They painstakingly carve “0000” on to a tablet and submit that to learn whether it’s right or wrong. In this case, “0000” is wrong. So they painstakingly carve another 4-digit number, “0001”, which is also wrong.

If the guess is wrong, the tablet is destroyed, and they have to start all over again. Let’s say that the time to carve one digit is 1 hour. So it takes team A 4 hours to make one guess.

Team B take a different approach. They guess one digit at a time, still carving them into stone tablets. They start by guessing that the first digit is “0”, which is wrong.

When their guess is wrong, the tablet is also destroyed, and they must start a new one.

Which team – A or B – would you bet on to guess the 4-digit number first?

Worst case, team A could take 40,000 hours. Worst case for team B is 40 hours. The odds of team A guessing right in the first 40 hours are 1,000:1 against. I’d bet on team B.

Now, let’s 10x team A’s “productivity” by giving them a machine that can carve one digit in just 6 minutes. Each guess now takes them 24 minutes instead of 4 hours.

Which team would you bet on now?

The odds of team A guessing right in the first 40 hours using the 10x machine are 100:1 against. I’d still bet on team B.

We’d be mistaken to confuse “numbers guessed” with “numbers guessed correctly” as our measure of productivity here.

What’s giving team B such a massive advantage is not the speed at which they produce tablets, but the speed at which they reduce uncertainty.

When team A make their first guess, the odds of it being right are 1:10,000. On their second guess, having ruled out one 4-digit number, they are 1:9,999.

When team A make their first guess, their odds of guessing all 4 digits correctly are also 1:10,000. But on their second guess, having ruled out all 4-digit numbers beginning with “0”, they are 1:9,000.

Basically, with each guess, team B reduce the uncertainty by a factor of 10%. Team A reduce it by a tiny fraction of that with each of their guesses. To put it another way, team B outlearns team A, even as team A out-delivers them by a factor of 10.

The takeaway for me is that – in software development, considered as a process of reducing uncertainty – it’s the batch size and the feedback loops doing the heavy lifting.

If your team wants to build the skills they’ll need to outlearn the competition, solving one problem at a time in tight feedback loops, visit my training site for details of courses and on-the-job coaching.

“Productivity”. You Keep Using That Word.

Bill writes a book with about 80,000 words. It takes him 500 hours.

Priti writes a book with about 60,000 words. It takes her 2,000 hours.

Which author is most productive?

It’s a nonsensical question, of course.

Maybe Priti’s book sold 10x what Bill’s did. Maybe it won the Booker Prize. Maybe Priti was commissioned straight away to write another book, with a big advance. Maybe Steven Spielberg bought the rights to Priti’s book and he’s going to make it into a blockbuster movie franchise.

Maybe Bill’s kids, who he wrote the book for, absolutely love it, and he doesn’t care what anybody else thinks. Maybe Bill’s book sold 100 copies and changed 100 lives. Maybe, in writing the book, Bill came to terms with a past trauma and is moving on with his life.

Here’s the thing about “productivity”: until we know what the goals are, it’s meaningless.

And if they have distinctly different goals, it’s also meaningless to measure Priti’s against Bill’s performance. Bill is apples, and Priti is oranges.

The industry’s recent obsession with developer productivity is equally meaningless. More code faster is greater productivity? More features? More Pull Requests?

If Priti’s book has more chapters than Bill’s, is Priti a more productive author?

If we create a software solution with the aim of reducing the cost of deliveries for our business, and the cost goes up, do we look in the repo to see if it was because we didn’t write enough code or do enough commits?

Or do we sit down and have a good long think about what changes we could make that would bring us closer to the goal? Do we observe the system in action to see where costs might be accruing?

And would that good long think and that observing end up as a statistic in some study about “lazy developers”, because we’re not producing more stuff?

Any formula that aims to describe software development productivity should include a term for value created. And teams should be empowered to move that dial – to choose their battles so their expensive and limited time is better-spent.

And “value” is very much in the eye of the beholder. What matters to me might not matter to you. It could be measured in dollars or pounds or yen. It could be measured in cats rehomed. It could be measured in meals on wheels delivered. It could be measured in lives saved.

And it’s usually multi-dimensional. Many businesses have been dashed on the rocks of a blinkered outlook, chasing one target at the expense of all others.

“If you give a manager a numerical target, he’ll make it even if he has to destroy the company in the process.”

– W. Edwards Deming.

Tensions within a business – like the HR team trying to improve employee morale while finance are cutting childcare – can be created by failing to consider the dependencies between outcomes, and to balance the needs of multiple groups of stakeholders.

With any goal, it’s important to explore how it might impact in different perspectives. Sure, we can cut costs on ingredients, but will the customers still enjoy the taste? All very well increasing margins, but for naught if we’re losing custom.

In the average software organisation, so little thought is given to why we’re building what we’re building. And when it is (usually by business stakeholders), those goals are not often communicated to development teams. It’s one of the most common complaints I hear from developers – nobody’s told them what that feature or change is actually supposed to achieve. What problem does it solve?

And this can easily translate into dysfunctions in the organisation of teams. Teams organised around technology stacks and technical disciplines -“front-end”, “back-end”, “database”, “QA”, “ops”, “architecture”, “UX design” – have about as much chance of achieving a business goal as a sack full of ferrets has of changing a lightbulb.

Smart companies organise around business outcomes, creating cross-functional teams of technical and business experts tasked with solving a business problem. We are on the same team because we share the same goal.

And when we iterate working software into the business, we have a clear idea of what it is we’re iterating towards, and ways to know when we’re getting closer to achieving it. Software development is an iterative, goal-seeking process.

Each release is an experiment. We don’t just push code out the door and move on. We observe as the experiment plays out, and learn for the next iteration.

Don’t optimise for delivery. Optimise for learning.

And yes, that’s going to create gaps in your commit history. But just because you shipped, that doesn’t mean you’re done yet.