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.
Developers, programmers, may have started the TDD ball rolling but it is managers who will finish the job.
2012?
ReplyDeleteWhoops, apologies, my mistake. I've edited the post and changed 2012 to 2022 which is what I meant originally.
DeleteThanks for pointing it out
"There is another force at work here: companies which don’t take quality seriously,"
ReplyDeleteSo if you aren't doing TDD then you can't possibly be taking quality seriously because TDD is the ONLY way to achieve quality. Is that what you are saying?
I have no problem with TDD and I think it is a good way to work but it is not the only path to quality. It sounds like you found something that works for you (good!) and now think there is no other way to create software.
Methodology is NEVER as important as people. If your team (from top management on down) all buys in and is on the same page your chances of success are good whether you use TDD, Waterfall, or whatever. If no one agrees then it doesn't matter what methodology you use because you are going to have problems.
Dear Anonymous,
ReplyDeleteIf you look at the above you will find I say: "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"
I happen to think TDD is the best we've got and I'm prepared to acknowledge there are other ways.
Which way would you suggest you reduce bugs?
I'll not deny people are important but so to is your approach and techniques. I've discussed this before:People or the system? - http://allankelly.blogspot.co.uk/2013/03/people-or-system.html
What techniques would you recommend for improving your people?
If you have none then we are down to pure luck. That might be the case but I'd rather it wasn't.
If its not luck then there is somewhere a technique, perhaps not a fool-proof one, perhaps not a 100% one but a technique.
While you say "I know it doesn't cure all known ills" you also seem to be saying (my interpretation) that everyone should be using it anyway because this is the best we have and if you aren't using it you "don't take quality seriously".
ReplyDeleteAs I said, I have no problem with TDD. However I disagree with the idea that it is the best solution for EVERY team in EVERY situation. If your people aren't buying into it (for whatever reason) you are going to have a hard time being successful. If they prefer waterfall (just as an example) and are gung-ho about waterfall the chances of success are going to be better with waterfall rather than forcing TDD (or any other methodology) on them.
I'm not saying don't have a methodology. I'm saying listen to your people and be flexible enough to find a methodology that fits your team best. That will increase your chances for success more than forcing a particular methodology on them.
Alan,
ReplyDeleteI think most managers see the costs of TDD as prohibitive, without really considering the business benefits. Here is a first cut at the business benefits of what probably could/should be the first thing to do when introducing automated testing (acceptance test driven development): http://www.agilelasagna.com/automated-testing-make-anyone-money/
The next question would then be. When is functional programming going to be commonplace? And once there what will happen to TDD?
ReplyDelete