September 2, 2010

...Learn TDD with Codemanship

Its Not How Fast we Deliver, It's How Fast We Learn

Just a little thought experiment for ya.

Split the room into 2 teams. (Yes, this is an imaginary room, and imaginary teams. But the splitting's real, alright?)

Both teams have to guess a 4-digit number.

Team A must guess all 4-digits at once. If they guess wrong, you tell them "wrong". And then it's Team B's turn.

Team B must guess one digit at a time. They guess the first digit. If they guess wrong, you tell them "wrong" and then it's Team A's turn again.

How many guesses might Team A need? It could be as many as 10,000.

Team B might have to make 40 guesses - 10 for each digit.

If we opened a book on this game, which team would you bet on?

Team B, obviously. They have odds of 250:1 of being the winner.

Okay. So let's speed things up a bit for Team A. For every guess you allow Team B, Team A gets 10 guesses.

So who would you bet on now?

Still Team B. They have 25:1 odds of being the winner, even though Team A delivers guesses at 10 times the velocity.

You can probably see where I'm going here.

In an iterative process like software development, over time what defines winners and losers is not how fast teams deliver features. It's how fast they learn about what works and what doesn't for their businesses.

Delivering less in each cycle actually helps them to learn faster. In software development, most of the value comes from acting on customer/user/market feedback.

Every feature we're asked to deliver is at best a guess. And we can cram as many guesses as we like into each cycle of delivery, but our productivity is not defined by this. It's defined by how readily we can act on the feedback we get with each delivery. The more frequent the feedback, and the longer we can sustain our ability to act on feedback, the sooner we will arrive at the real value in what we're creating.

In a market like Video-On-Demand, we can be sure of one thing. Whatever strategies work today, they will probably be irrelevant tomorrow. The challenge of products like YouTube, iPlayer and Canvas is in recognising that continuous, sustained evolution in years to come is what will define the market leaders, not fast delivery to gain market share in the short term.

Software development's a marathon. You cannot break a 26-mile marathon down into a sequence of 100m sprints. You run the inevitable risk of sacrificing the race just so you can have the fleeting honour of being in first place after the first few hundred metres.

Technical debt is a useful analogy, but I find lactic acid much more compelling. If you start a marathon at a sprint, lactic acid builds up faster in your muscles and you'll very soon find it impossible to go on.

If you "sprint" to deliver code, the crap builds up faster, too. I've seen so many software-intensive businesses rush at the start to take an early lead, only to end up being carried off on a stretcher a year or two later while their more disciplined competitors slowly but surely creep ahead and end up in front.

I'm pretty sure the bright young things who are tasked with consulting for the government on these issues and the whole Digital Economy thingummyjig here in the UK - brilliant though they undoubtedly are - have overlooked this. I don't see it mentioned in any of their literature, and as a software development coach working in this space, I'm not aware of any software developers being consulted about it.

Software craftsmanship is one of the defining factors in the long-term success of digital businesses (as well as traditional businesses who rely on software, which is pretty much every major UK company these days).

I don't dare to imagine that those charged with shaping the UK's digital strategy will even begin to comprehend how important clean code is in the overall equation. But the logic and reality is inescapable. If code is hard to change, it cannot easily evolve. And if software cannot easily evolve, our digital economy could end up being carried off on a stretcher in the not-too-distant future with crippling muscle cramps and exhaustion.

We humble, voiceless and invisible code monkeys are actually a critical limiting factor on the fortunes of "Digital Britain", every bit as much as the people who built the ships and railways and bridges were for "Steam Britain".

I do not expect the government to acknowledge this. I do not expect building the UK's software development capability will ever be much more than a footnote at best in the digital strategy.

So I guess it's down to us. We can lead by example. Hopefully if enough of us show the way and commit ourselves to the goal of continuous delivery of clean, reliable code, and to being ready, willing and able to adapt our code based on feedback, the people who pay us will get the opportunities to learn and evolve their products and services fast enough to keep pace with the competition.

Chances are nobody's going to ask us to do it. And we probably won't get paid more if we do it. Likely as not, they won't even thank us.

But deep down, we care, and that's why we know it's the right thing to do.

Posted 10 years, 7 months ago on September 2, 2010