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 2012 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 2012.
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 loose 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 2012 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.
Should it be 2022 and not 2012
Yes, 2022, sorry, – I fixed it in the original blog (finger error, or fraudian slip) but I don’t think its made it to the syndicated versions.
allan