In a consulting company where the general thought of TDD and automated testing as a whole is appreciated by the programmers but thought of as "been there, done that, doesn't work" by management, how would you convince the powers that be to approve the investment of time and resources to implement such an approach?
So, to be specific, this is not a question on why is TDD good but how to encourage management to adopt the practice?
If you are looking for a business case for TDD point to reduced development time (i.e. cost) due to re-work. From my experience in consulting it shouldn't be hard to find a project that was developed in house to use as the negative example.
You can't convince managers of much except by a review of historical facts.
You can do this to show them that more tests == better quality. First, write more tests. Then show the quality improvements.
It takes a while to see the improvements. Many folks say that time is "wasted" writing tests, because the time should have been spent writing the software "correctly" the first time.
One of the immediate benefits of TDD is what happens when you have a vague specification. You can't write the tests to begin with. You've already improved quality by considering testability very early in the process.
A later benefit is software that really works.
Still later, you'll find that you can refactor without breaking anything. Management doesn't believe refactoring is hard, so you won't win any points with this observation.
Finally, you'll be able to maintain and enhance the software more effectively with adequate tests. But this benefit won't be seen for quite a long time.
I've found that the best evangelism is done by providing a good example. If you write tests and others don't, your code will be more stable. If you use TDD and others see your work and the clarity you have when designing and implementing, they'll want to use your methods (TDD).
If you issue a mandate for TDD, I've seen minimal acceptance.
For the long term (maybe too long in your case) hire only people who are passionate about testing or TDD.
Increased code quality, which reduces maintenance cost is a good "dollars and cents" argument in favor of TDD and automated testing. I also find that pushing unit testing instead of the whole TDD methodology is an easier sell.
My question for you is, why does management need to endorse it? If the programmers where you work are already in favor of TDD, why aren't they just doing what works?
"Been there, done that, doesn't work"
LOL. So does that mean after failing one software project you give up on ever writing software again?
Different implementations and people lead to different results. Sounds to me like they don't understand the full benefits of doing it properly.
If they aren't doing TDD, what are they doing? Bottom Up Design? None?
If they are using BUD, It's a different philosophy and you many have the ability to change their minds (and perhaps you shouldn't).
IF they have none, then they have bigger problems. To take a page from J.S., lead by example. If someone gives you an assignment and they don't have a spec/design; write one and get them to sign off on it (even if it is one page).
Write your own automatic test cases to prove out your modules. etc. When something breaks, you can then show (in a matter of seconds) that your modules are not at fault - they conform
If management won't accept the practice, but the developers could be convinced to, then what you really need is to convince management not to stick their nose in your development practices.
That way, you can do "(Test|Behavior|Cheesburger) Driven Development" as much as you like, and you don't need to convince management again next time you want to adopt a better practice.
The answer is quality. Management needs to understand that tested code is higher quality code. Higher quality code is less expensive to maintain. But there's a domain problem here. If your company produces one-off websites that it doesn't have to maintain then they don't care about the long term cost of code. If they're building a product that they can sell, upgrade, sell again etc. then the quality of code matters a lot. If your managers don't care about quality then maybe you should look for a new job. I dare any manager to say they don't care about quality. Ask em point blank.
Another point: Ask them: Does our software work? Of course they will say yes, we have testers. Then you can discuss whether testers ever miss things the second or third time they look at something. They do, naturally. Unit testing is reproducible: the 100th time that test is run, will be the same as the 1st. That's something that is impossible to get with eyeball testing.
There are certainly parts of your application that an end-user will get to very rarely. Does your eyeball tester test these things every time? Probably not. If they do, it's a tedious job and a waste of time. Unit testing can automate this and test the "hard to get to" parts of your code every over and over again, with minimal time investment.
I found this paper that took a structured approach to your question. From the abstract: "Experimental results, subject to external validity concerns, tend to indicate that TDD programmers produce higher quality code".
You could try asking management how much time and money they think might be lost when defects or issues are detected late in a project/iteration/release (i.e. they become more costly to address or fix).
TDD, by virtue of better unit test coverage and proving designs early, could potentially save the company a great deal of time and money because issues are detected earlier (even during initial design), and thus can be resolved or addressed faster, saving time and money.
Edit: I know a lot of people have been saying "quality" (which is important) but I've seen businesses pass over "quality" for decreased time-to-market and many other (many times dubious) reasons.
IMHO if you mention "it saves cost/money/time" you might have better odds at getting their attention - most businesses like the sound of reduced cost.
So, to be specific, this is not a question on why is TDD good but how to encourage management to adopt the practice?
I'm skeptical the situation is as you describe. Are you sure you aren't looking for management to mandate TDD?
Because if it really is the case that the programmers are in favor of TDD then you can do TDD. Management doesn't really get a vote on that unless they're pairing with you!
From my perspective as a project manager, the answer to “How do I encourage adoption of (x) development practice” is almost always: DO IT SLOWLY.
Implementing a new development practice can be very hard, especially if it happens via coercion. It's easier if you lower expectations of immediate impact and instead look for opportunities for incremental change.
Since you know how to develop software, it might be helpful to think of Development Methodology Improvement as a project (meta-project?) of its own. The customer is the management team, and the "shipping product" is an improved process. The specific techniques you use to make that product can be as varied as the many patterns you use in a software product. In your case, you're pretty sure you want to use the TDD pattern; but ultimately you should recognize that another pattern could be a better approach.
First, work with the customer to identify the user stories**. (Don't get sloppy here—“fewer bugs” is not specific enough to measure.) Then prioritize them. Then figure out how to show progress in a single iteration. For example, you could show progress by writing tests for a single feature, with a single management representative "pairing" with you, i.e. looking over your shoulder as you write it. This doesn't take a ton of extra time or effort on anyone's part, but the end result is that one feature is more reliable and one manager has more understanding of TDD.
Over successive iterations, you add more tests or involve more coders/managers, or whatever you can do to show continual progress. The key here is that the changes aren't too disruptive to the existing process. The team is still focused on the software, not the process, so management doesn't freak out about wasting resources.
**Don't call them “user stories” if you aren't using that terminology already. Use whatever words you currently use to specify problems that a software product will address.
First of all you have to make the management see the problems they are facing now that could have been avoided if TDD had been used. Without TDD it is likely that you will suffer from:
If they can see that a certain practice, such as TDD, can solve some of their problems then they are more likely to try it. Most managers will not introduce new practices for its own sake.