March 21, 2016

...Learn TDD with Codemanship

Do We Want To be Musicians or Pop Stars?

One of the dirty little secrets of our purportedly meritocratic, "survival of the fittest" tech business scene is that bad products win over better products all the time in the marketplace.

We can point to marketing, to sales, to management, and even the way we went about writing the software, to explain why Product X succeeds over competing Product Y. But that would just be another example of our human need to explain the inexplicable, seeing faces in what is really just mostly noise.

When you read the stories about the biggest software successes, you realise that they're a product of an increasingly improbable series of lucky breaks - like an accumulator at the horse races. Some people just get very lucky and win big.

Of course, their products have to be good enough and their businesses run well enough to keep them in the race. Just like a pop record has to be good enough, and the band managed well enough, to give them a chance of chart success.

But, like the pop charts, the smash hits of software are a predominantly mediocre bunch. Facebook? Meh. Twitter? Whatever. Apple? Yawn. YouTube? I tolerate it. (And before any Apple fanboys and fangirls complain, two words: i. tunes.)

We can all think of competing technologies that did it better. My favourite example is Delphi vs. Visual Basic. How on earth did Delphi not win that one?

Well, the answer's simple: luck. Not greater skill. Not greater marketing. Not greater product management. Not greater software development. Whether it was Microsoft's good luck, or Borland's bad luck, it all ends the same.

People forget that, in the late 80's, as far as development tools were concerned, Borland was it. Delphi followed hot on the heels of the widely successful - and widely loved - Turbo Pascal. As was Turbo C and C++, another competition they lost to Microsoft. The market was theirs to lose. And lose it they did, eventually.

But why did they lose it? And this is what this long, rambling blog post is really about...

Routinely, when I extol the virtues of a development practice that someone doesn't really want to do, one objection they'll raise is "But can you name me a commercially successful product developed that way?"

And maybe I can and maybe I can't. (But let me save you some time; if you ask me that question about TDD, refactoring and continuous integration, then I can.)

But asking a question like "So, if X is so good, can you name a successful product done using X?" fails to recognise that there's no direct causal link between "doing X" (no matter what X is) and big commercial success. Because big commercial success is largely a product of luck, and mediocre products succeed all the time.

This is just like it is in pop music. "Can you name a hit record where the guitar player held the pick that way?" doesn't seem like a very meaningful opener to a conversation about better ways of playing the guitar. When people learn to play musical instruments, there typically isn't a "How to have a hit record" element to the instruction. There is no Hit Record Technique for guitar.

And there's no Hit Record Technique for programming, either. Like musicians, we programmers can only do our best... and then hope for the best. Only delusional programmers think in terms of "if I check my code in more often, we'll gain 25% more paying users". We just don't know. It's all guesswork, and I've seen some great products, beloved of the users who got to try it, languish on dusty shelves and I've seen some awful software - the kind users curse the day they ever installed - in very widespread daily use. (Cough) iTunes.

Of course, iTunes is widely used because of iPods and iPads and Macbooks and iPhones. It has inherited its user base. Which is just another kind of dumb luck. iTunes is the Donald Trump of consumer software.

And lest we think that any media player can piggyback off a large installed base like that, ask ourselves why Windows Media Player didn't smash iTunes out of the park.

So judging whether or not a development practice works purely on the commercial success of products built using that practice is not helpful. Big commercial success is not a good indicator of intrinsic merit. Just because Netflix do it, that doesn't make it good.

Putting aside the money, quality still matters. I didn't pay a thing for my copy of Eclipse. But it still matters if the automated refactorings work. And it still matters if there'll be future enhancements. The intrinsic features, usability, reliability and maintainability of Eclipse matters, regardless of its market share.

My fear is, by focusing on the £££, we end up sending developers a message that - to revisit that metaphor - why bother learning more than 4 chords if most chart hits are made using the same 4 chords?

And then we have to ask ourselves: what do we want to be? Musicians? Or pop stars? Because 999 out of every 1000 who set out to become pop stars end up being neither.

Posted 1 year, 7 months ago on March 21, 2016