March 7, 2011

...Learn TDD with Codemanship

"But What If We're Building The Wrong Thing?", And Other Lame Excuses For Writing Shitty Code

I had a very interesting couple of days in Finland, hosted by those lovely folk who organise the Scandinavian Agile conference. (Which was jolly good fun, by the way.)

In the bar after the conference, I got into a familiar discussion about software craftsmanship, which goes like this (sing along if you know the words):

"But does craftsmanship matter if we're building the wrong thing?"

(I should stress the chap asking was playing Devil's Advocate, and nt advocating actually writing shitty code. But it got me thinking all the same, as I get asked this question A LOT.)

A reasonable enough question. If you've just spent a squillion dollars on software nobody's going to use then it probably doesn't matter if the code is reliable, readable, simple, modular and all those other things us craftsmen - and craftswomen - bleat about all the time.

Except... well, let's think this through.

First of all, did we know we were building the wrong thing while we were building it? If we did, then why did we build it at all?

If we didn't know that we were building the wrong thing at the time, then why would we risk the future of that software - which we hope will be successful - by cutting corners on code quality?

In the vast majority of cases, software is either worth writing well, or it's not worth writing at all.

This is especially true because, as we've learned from decades of experience and dozens of large industry studies, it doesn't necessarily take longer or cost more to write cleaner, more reliable code.

To me, it would seem irrational to choose to cut corners. Given that we can produce better code at no extra cost, and given that if code is worth writing at all then it's worth doing a good job of it, why on Earth would we choose to do a worse job?

A similar argument goes something like this:

"Sometimes you just need to do something quick-and-dirty to get it to market and learn some lessons"

I'm calling bullshit on this, too. In software development, we've found - and the jury really isn't out on this one - that the reality is actually quick-and-clean vs. slow-and-dirty, even on relatively small and simple problems.

But let's say I'm wrong. (I know, perish the thought!)

Well, let's say we did a bad job of building the wrong thing. What next? The user feedback starts flooding in, but we struggle to respond because we're devoting most of our time to bug-fixing, and making changes to the code is expensive and risks breaking existing features. And to make the software useful and usable enough, we have to make a heck of a lot of changes. So the code may likely-as-not get thrown away and we start again. But was every single line of it without value? Are we being forced to throw the baby out with the bathwater? or could we have adapted it into something more useful, had we not had such a mountain of technical debt standing in our way?

And what about our quick-and-dirty (which was probably actually slow-and-dirty, but let's pretend for a moment) prototype? Well, we'd better hope we got it 100% right with that first release, because, again, if it needs to evolve, there'll be a mountain of technical debt standing in our way.

Now maybe, in both cases, throwing the code away and starting again really is the best medicine. But wouldn't it be less risky to give the customer a choice? I've only ever seen code bases being ditched out of absolute necessity - always as a last resort on the part of frustrated and angry businesses. Our shitty code backed them into a corner.

Uncle Bob Martin, Steve McConnell and others correctly assert that the quality vs. time/effort trade-off in software development is largely a myth. And demonstrably so.

In that respect, software craftsmanship can give customers more choice by essentially giving them more throws of the dice at the craps table which is software development, and at no extra cost or risk. If we believe that most of the real value in software is discovered through feedback and learning (which is what Agile was all about), then craftsmanship is value-focused because it enables more feedback and for longer. It enables businesses to learn faster.





Posted 7 years, 1 month ago on March 7, 2011