Andrey Khavryuchenko himself

How to convince boss to use TDD

Some time ago I was contacted to find arguments to introduce Test Driven Development into a company process. Or, at least, start doing some automated tests.

Quick chat revealed that, while doing iterative development and having dedicated QC team, during the 2 year age of the product, the pace of development is slowing down and with each next release it becomes more difficult to get it out of the door. Some defects even creep into production.

If that would be a service company, like ours 42 Coffee Cups, I’d suggest to do a small pilot project using TDD and compare metrics. Product company, unless they want to run a controlled experiment (or a side project) are left only with comparison to foreign projects.

As we’ve dug deeper, it became obvious that team lead, who contacted me, made no efforts to baseline team performance.

They do use JIRA, do weekly iterations, but yet, it’s used just as a sophisticated todo list.

Since team lead guess was that pace is directly affected by bug count and this is related to the codebase size, the obvious metric would be the number of defects found (weekly) compared to SLOC count. Hypothesis to be proved: the larger amount of code gets – more defects per KSLOC pop up. While it is obvious to the lead, it is far from obvious for budget holders.

Their arguments:

• we have already large codebase, no chance to cover it with tests in realistic timeframe and budget
• tests are hard to support
• the effect of tests is not obvious
• tests double development time

From that point on, it was obvious how to advocate for automated tests:

• we may start with tests for just new code and bugfixes
• that’s not true (and provide proof references)
• … and here is the effect of tests absence! – and show the graph (defect per KSLOC) vs KSLOC total
• tests do not double the development time and their absence cost real money – and again show the graph that shows defect creep

Final suggestion was to introduce test in guerrilla fashion – just start writing unit tests for defect fixes.