Suggestions for "Selling" TDD, and BDD to sceptical non engineering managers

Question

Let's say you are a developer (specifically, the team lead) and you want to improve the quality of your company's products. Since you cannot change the whole company, you focus on what you and your fellow developers can do to enhance the quality of the applications you create/maintain. You decide that this can best be done by embracing TDD for class verification and BDD for integration testing.

Since we are talking about .NET development here, let's be specific and use:

• MSTEST as a unit testing framework for the TDD
  As a development house you already use TFS 2010 so the MSTEST solution is a given with its integration of code coverage and test pass validation at check-in.
• SpecFlow for the BDD
  SpecFlow is more subjective, but I propose it as a BDD tool as it integrates well with VS 2010 and source control, and the gherkin/cucumber syntax is, I think, easier than that of Fitnesse.

Moving from "coding with ad hoc testing, followed by a release to QA" to a "TDD/BDD" approach will save time and money over the life of an application—but, it will extend the time a program spends in development over the ad hoc approach (although arguably the QA time should reduce as QA should then mostly find system test faults rather than those and integration and class bugs devs now find and fix sooner).

Assume some minor TDD/BDD projects have already been completed so your company is not overly nervous about the technology, but have yet to "go for it" with a full size project.

But in this business, development is a different cost centre from QA, and both are different from support and operations.

So, how do you sell the benefit to the company of adopting TDD/BDD to development managers who are held to account for the increased cost (i.e., time) of the development department?

This, to me, is all the harder given the benefits of failing early, etc. seem largely unquantifiable.

How do you go about winning hearts and minds on the topic?

Answer 1

One of the realities about corporate politics (I hate to say it, but it's a big part of our job) is that everyone wants to put out the image that they're open minded and willing to do what's best for the company, but in reality most people want to go with what is safest for their career and with what they know and are comfortable with.

< tangent > If you're familiar with the movie A Few Good Men, you know the famous "You can't handle the truth!" scene. The Colonel ends up getting caught by saying one thing, and having actions that contradict it. While I don't recommend you go yelling at each other like they do in that fictional courtroom, I do think a lesson can be gleaned from it. < /tangent >

I would ask the question What would it take for your confidence in TDD to warrant trying it on a large scale project? If you can get them to give you some criteria to meet, then you have something to aim for. Go, meet those criteria (you may find you actually already do!) and then come back and say that you have fulfilled the trial criteria, and in your estimation your team is ready to test the waters on a bigger project.

If they can't give you a straight answer why to not go for it, they're simply xenophobes and honestly you can't expect their minds to ever be swayed. At that point, it's time to have lunch with a VP (with some case studies, including internal success) or time to fire up Petes_resume.doc.

Answer 2

In my experience, you can't sell new development processes. The only path I've found which works is to simply start doing it: Only develop with TDD from this point forward. You'll still deliver your code on time, but it'll be more maintainable and have far fewer bugs. You'll feel much less anxiety and be proud of your work.

After a little time, management will notice these positive outcomes far beyond the norm. When they ask about it is the time to talk about TDD.

Caveat. Granted, this is far easier is you're on a smaller development team and a new project or job. In my current job, I began using TDD from day one, and it's simply how I work there. I've earned a reputation of delivering bug-free code which runs faster and uses less memory than the code it replaces. I've gotten small, subtle push-back just once on TDD: "Your tests are longer than your code!" I blew it off. It doesn't matter, because I'm producing beyond expectations — no one else uses a testing methodology, and most code written by my group is chaotic.

Answer 3

"it will extend the time a program spends in development"

Initially, this may be true but as the software matures and becomes more complex, the TDD approach will actually reduce the time a program spends in development since the code-base will be more robust, easier to maintain and less prone to bugs.

Once you have good unit test code coverage and a full suite of acceptance tests you have effectively defined the "behavioural boundary" for your software. Any developer who breaks this behaviour during later development will be alerted to it immediately in a TDD / Continuous Integration environment.

Being alerted to bugs almost instantly (Failing Fast) is a huge cost saver for the software industry and one any development manager worth his/her salt should be very interested in hearing about.