Unemployable without TDD – a follow up

The reaction to my last entry – Programmers without TDD will be unemployable by 2022 – took me a little by surprised. I expected there would be a reaction, perhaps a big reaction, but I frequently expect some reaction and usually I get none. This time I got a reaction and the scale of the reaction continues to surprise me.

Particularly gratifying are all the comments on my blog, on DZone, JavaCodeGeeks, and probably some other sites that syndicate my blog but haven’t bothered to tell me. The fact that people were moved enough to write anything, supportive or not, means I caused people to think and join the discussion.

I’ve come back on many, certainly not all, of those comments directly but I won’t come back to every point. In this post I’d like to touch on a few of points which I think need expansion or clarification. Sorry if you think this is me being defensive. Stop reading if you think so, consider this a blog post for one reader only, me!

(This post, and a couple of others coming out of the TDD post does mean it will be a little while before I can get back to my software economics series.)

First, the many cynical comments (e.g. “This seems unlikely”) don’t surprise me. I frequently come across such cynicism in my work. Indeed, were such cynicism not widespread then I don’t think there would have been much interest in the prediction or any point in making it.

I am rarely sympathetic to arguments that it “won’t work for me” or “won’t work in my domain” because overwhelmingly these arguments are at best a (flawed?) logical argument, but they are usually made without trying it, they are conjecture, . When someone comes and says “We tried it… we really tried it… we invested in it… we stuck at it for a few months… and it made us worse” then I’ll accept it as so. Usually I find people who argue against TDD have never tried is or tried it superficially.

Second a point of clarification. I am happy to acknowledge that there are other ways of reducing a defect count. Code reviews spring to mind. There is a lot of research that shows that when done well they can be very very effective – and also justify the time spent.

Over dinner the other night Phil Nash also suggested highly typed functional languages – or was it functional languages and strong typing? I’m sure Phil is right in both points eitherway. Although if you ever saw the any of the Lisp/Scheme I wrote in college you would know bugs are entire possible in functional languages!

The point is: there are other techniques, probably some I don’t even know about. I single TDD out because a) I know about it and b) I think it has achieved critical mass and will be adopted more widely in future.

Because of alternative approached there will still exists jobs where TDD is not a prerequisite but they will be few and far between, in particular niches. There will be a few jobs you can get without past TDD experience but you will be expected to learn it. The same way you can occasionally get a job as a Java programmer even if you have never programmed Java. But if I was still developing, I won’t like to bet my career on finding such jobs.

Next, and most gratifying, the discussion on Twitter and in blog comments that followed the publication flushed out several companies who already operate a policy of only hiring developers who practice TDD. 7 Digital and Compare the Market stick in the memory because a) I’ve known them for a while and more importantly, b) they are hiring! Thanks guys, consider yourself plugged.

A few other people tweeted or commented to say they personally operated such a policy but didn’t give company names.

So let me float a hypothesis – based on the fact that I regard TDD as a better way of developing code than not doing it:

The divide between productivity and value-add of companies which do TDD style development and those which don’t is growing. The first group are generally among the best, most productive, highest value add, and the second group which don’t TDD are a long way behind. The first group is accelerating onto BDD, Continuous Delivery and other “new” ideas, while the second aren’t.

Sure there are companies which say they do this, and there are companies where application is not consistent – some people do and some people don’t. For such companies to join the high performing ones they need to do more and do it more consistently.

There are networks effects to doing TDD: the more people who do it in an organization, and the more consistently it is done then the greater the benefits. If one developer starts doing TDD their code will be better and everyone will benefit, but with each extra developer doing it the benefit grows greater per person – there are economies of scale here. And when everyone does it then the benefits are far more than the sum of the parts.

Yes this is conjecture, or if you prefer, call it intuition.

I don’t know what form it will take – I think it will be mixed up, some will be methodology, some will be more relaxed, and it will differ from place to place, team to team.

Next there was some discussion of how the transmission mechanism, how would TDD being good actually get it inside corporate IT departments? That is something I’ll come back to in another post, I have a view on that which might poor petrol on this particular fire.

People also threw stones at me on Twitter because my company sells TDD training. Lets get this straight: we offer such services because we believe in it, because I believe in it I wrote blog posts like I did.

It is insulting and extremely cynical to suggest that I write blog posts like I did purely to sell training. It would be nice if life was that simple, you would see more blog posts like that and I would be a lot better off.

Now I’m not saying you have to have training to learn TDD – although I do recommend it. I am also happy read Steve and Nat’s book, Growing Object Oriented Software – and yes, that is an Amazon associates link, is that a crime? I make about £10 a year from such links.

But ask yourself, if you were to buy such training who would you rather buy it from? Someone who sells it as another course or someone who passionately believes in it?

Before I finish, two other things about the reactions post surprised me. That so many people railed against my aside comment about IDEs. Of course IDEs will still exists and will still be useful. I just suggested that would be less because they were debugging environments and thus we might see changes in IDEs.

Also, very few people mentioned my comments about University courses. In many ways those comments were the driving force behind writing the post. TDD is a proven technique and Universities should be teaching it on programming courses, and they should be teaching code reviewing and probably some more techniques too.

Finally, as someone else pointed out my prediction is a safe bet. If by 2022 I am proved wrong nobody will remember my prediction. And if I’m proved right nobody will care when I say “told you so.” Besides, I expect people more famous than me will make similar predictions – both for and against – and they are far more likely to be remembered than me.