Managers who don't TDD be unemployable before 2022.

In the furious discussion over my “Programmers without TDD will be unemployable” last month a couple of people asked: “How will this come to pass?” And a few others said: “Managers will never let this happen.” Let me answer both these comments in one go:

Managers are the missing link between today’s largely TDD-free code development and the 2022 world where TDD will be essential to get a job.

I know not few managers are perfect. And I accept that there are managers out there who might not want their developers doing Test Driven Development. But in my experience you don’t need to be a perfect manager to understand the logic of TDD, a quick look at the Microsoft research study should address that.

And in my experience it is developers rather than managers are the biggest block to practising TDD effectively. I can usually persuade a manager that their developers should do TDD. I can even (sometimes) - putting on my salesman hat - persuade them to spend money on training and/or coaching for developers to learn TDD.

What I find a much greater challenge is persuading developers that TDD might be beneficial to them. That TDD might help them find bugs quicker, or that their legacy code would benefit, or that it will help them separate business and UI logic. Just persuading programmers to code in a different way is hard.

And it is even harder to persuade them that having some help, going on a course or having some coaching, is a faster route to proficiency than reading a book and watching some screencasts.

I know TDD is not a panacea but I do think it is the best we’ve got right now. I know it doesn’t cure all known ills. And I know that in some cases the wrong solution, I know that other techniques - code reviews and functional languages for example - can also reduce bugs but…

Firstly too many developers question TDD without properly trying it, and they propose alternative remedies which also fail to get tried.

Secondly, as I said: managers are not perfect. You don’t need to be a perfect manager (indeed few, if any, are).

I predict that once Development Managers get the TDD-bug they will over do it. TDD will be mandated even when it is not applicable, or when another solution might be better. For a while TDD will be a management fad.

That also mean that the style and quality of TDD will be massively variable. Like Agile before it will be a buzz-word for the developer CV (resume) and more importantly, for the Manager CV.

In the same way that Managers will not employ Programmers who don’t know how to TDD - and are not enthusiastic about it - Managers will not get employed if they don’t expect their programmers to do TDD.

Managers who think TDD is a waste of time will be unemployable before 2022.

Even managers have managers. Even managers need to get new jobs from time to time.

I often meet programmers who tell me “I would like to do TDD but our managers won’t let us” but I have never met a manager who has ever said: “My programmers want to do TDD but I have forbidden it.” Managers, particularly the better ones, are open to hearing better ways.

Look at the blog comments after the “Programmers without TDD” post - on my blog, on DZone, JavaCodeGeeks and the other sites where it was syndicated. There are several programmers saying “Managers won’t let it happen” or “It doesn’t work” but I don’t recall even one manager saying “I’ve stopped my developers from doing TDD.”

Whenever a programmer tells me “I would like to do TDD but my manager won’t let me” I ask: “Have you actually asked the manager concerned? Have you discussed it?” invariably the answer is “No.” Programmers assume their managers’ will not like it.

The quality movement wasn’t always popular, people questioned Philip Crosby’s Quality is Free logic, it took time for the chip industry to change (The Anderson Bombshell) and it took over 20 years for Ford, GM, etc. to match Japanese (Toyota) standards but today you would not get very far if you suggested the Austin Allegro was a good car.

There is another force at work here: companies which don’t take quality seriously, or can’t change fast enough, will lose out to those who do. In the early 1970s British Leyland, later Austin Rover was the third biggest car producer in the world. The bits of the company that embraced quality - Mini, Jaguar and Land Rover - still exist, the rest doesn’t.

The manager connection also explains another question that was posed following my first blog. Several people said: “I can see how software companies get this, but inside corporate IT they will never buy this.”

I understand where these people are coming from, software companies will be the first to mandate TDD, most corporate IT departments will be slow on the uptake but they will come round because:

• Corporate IT has long copied software firms but after a long delay. This pattern will play out with TDD too.
• While some people work their entire careers in corporate IT there are also a lot of people who worked in software companies earlier in their career (such businesses often pay less than corporate IT.) By 2022 the people arriving from software companies into corporate IT will expect to do TDD. And the managers arriving in corporate IT will expect their programmers to do it too.
• Consultancies like Accenture, IBM Global Services, Tata etc. who do outsourced work will pick up TDD from software companies (they see themselves as software companies). When people move from these companies to corporate IT groups they will take TDD with them, when software passes from the outsourcer to the client it will come with tests, and when corporate IT looks for best practice (O, how they love best practice!) they will find TDD.
• Graduates from the better colleges and universities will also arrive expecting to do TDD.

If you followed the comments and Tweets surrounding the original post you will have seen several people say their company already mandated TDD for new recruits. Each one of those companies, to the best of my knowledge, has high performing teams which deliver software which contributes directly to company success. Why wouldn’t a manager want that?

Developers, programmers, may have started the TDD ball rolling but it is managers who will finish the job.

Manual testing sinful?

One of the asides I made in “Programmers without TDD will be unemployable” which caused a bit of outrage in the testing community was my comment “Manual testing is a sin.” While I have been unfair to many testers, and somewhat simplistic, I still stand by the statement. Let me expand on why I still stand by the comment and why I am wrong.

It is all a question of context. Look at the full line the quote appeared in:

“Unit testing will be overwhelmingly automated. Manual testing is a sin. Manual unit testing doubly so.”

In the context of Unit Testing, as one who has undertaken formal and informal manual unit testing I believe unit testing can and should be fully automated. Informal unit testing is too ad hoc, prone to error, time consuming and difficult to replicate. Formal manual unit testing suffers all these problems and is hideously expensive.

In the context of unit testing I stand by “Manual testing is a sin.” I will also go further.

The vast majority of testing I see performed by professional testers - i.e. not unit testing - is manual, the vast majority of this testing could be automated. If you automate the testing the initial costs might go up - I say might because a good natural language test script is expensive to write itself - but the cost of executing the test will fall. More importantly the time it takes to run the test will fall dramatically.

The combination of low cost and fast turn execution means the tests become a very very effective feedback loop.

Failure to seize this amazing opportunity is something I consider sinful. It may be expensive but it is necessary. Even seizing 20% of this testing would be massively beneficial.

What I do not consider sinful is Exploratory Testing which almost by definition cannot be automated and therefore needs to be a manual process. Exploratory testing is about looking for the unusual, the unexpected, the thing you didn’t think of before, the thing you only think of because you now see it.

Automated exploratory testing might even be a contradiction in terms therefore manual exploratory testing is not sinful.

But, and this is a pretty big BUT: if the initial quality is low (e.g. unit testing is absent or poor) and the testing (e.g. system, integration, acceptance testing) that comes before exploratory testing is ineffective then exploratory testing will be effective at finding defects (because the earlier rounds didn’t find them) but it will be ineffective as exploratory testing.

The time and effort spent on "exploratory testing" is really being spent doing system testing. Real exploratory testing itself will not be possible when there are many defects because the exploration will continually be interrupted. 

Unfortunately the subtlety of this logic is lost on most organizations who just label everything that happens after writing actual production code “testing” and is made worse when testing is separated from the developers and, more importantly, those who understand what the system should do (the business, the BAs, the product managers, the users, etc.)

Worse still, the easy availability of cheap offshore testing capability means that rather than address the root cause of defects (low initial quality, system ineffective testing, misunderstanding of exploratory testing) means the whole thing can be hidden away cheaply.

There are probably some other examples of testing which cannot be automated and are not sinful. But I repeatedly find individuals and organizations who too ready to jump to “it cannot be automated” after very limited, or no, effort is spent on trying to automate it.

Similarly the fact that a professional tester cannot automate the testing of a piece of software system does not mean it cannot be automated. Automated testing - at least the setup - involves programming skills which many testers simply do not have, indeed it is wrong to assume they would have them.

Finally, there are a class of systems which as far as I know defy automated testing. Or rather defy automation at the moment. They defy automation because the creators of these systems have little or no interest in allowing automation. This set includes: SAP, Microsoft Sharepoint, most CRM systems such as Microsoft Dynamics, Murex (although I believe efforts are afoot here) and some other large packages.

I find it incredible that companies like SAP, Oracle and Microsoft can sell systems which cannot be effectively tested. But actually this is part of the sales-pitch. Because these systems are marketed and sold as “no programming required” to offer automated test tools would expose the lie. If you are involved with selecting one of these systems ask: how will we test it?

The inability to effectively test these systems is their Achilles heal, it is one of the reasons I don’t like these systems and it makes me wonder about whether organizations are right to use these systems.

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.