Test Driven Development for the management point of view

When I have given presentations on TDD, one of the biggest questions I get is “How do I sell this to my boss?”, and it’s a very valid question, you are basically asking your boss to let you write 2-3x as much code to make sure the code you wrote is correct, that’s a tough sell all on its own.  Software can never be done soon enough, most projects are already behind from the start, and now you want to take more time to write more code? 

Time is Money

There is a cost to Test Driven Development (TDD), you are doing more work, writing tests takes time, maintaining tests takes time, and running tests takes time.  With time equaling money the question is “what are you buying?”, the simple answer is security, and long term cost reduction.

Ever wonder what it would be like to have a car without a check engine light?  For the most part it’s something most of us never look at.  When it turns on we take it to the shop and the mechanic fixes whatever is wrong.  Without the check engine light to tell you something is wrong, what could have been a small repair is now an engine rebuild.  Having tests provides you with the same thing, it lets you know there is a problem before it becomes a larger problem, this could be inconsistent application behavior, data corruption, or the application crashing.

Real world example

At a former employer we were migrating to a new production database for our flagship application, the database it’s self was a very complex system, lots of tables, triggers, stored procedures, etc.   The DBA migrated the schema to the new server, got a snapshot of the data and then ran our integration tests and had failures everywhere, invalid permissions, missing columns, etc.  Even using the failed tests as a road map to took the DBAs 1 ½ days to fix all of the problems.  I can’t even guess how long it would have taken to fix if we would have just done to production, on top of that the company’s main product would have been down, not only affecting us, but also all of our customers that depended on our product to run their businesses.    

We Could have just blamed the DBA for not getting everything right the first time, but at the same time, how much time was he given to do it, would it have been cost effective to spend more time for this one time, verses spending the time writing tests that can test it over and over again.

Spending a little to save a lot

Software bugs have costs: they cost to find, they cost to track, they cost to fix, they cost to verify when fixed, and they cost to push out the fix. 

• Cheap - A developer finds a bug when it was written, he/she fixes it, very little cost
• More Expensive - QA finds the bug, the tester needs to make sure it’s an actual bug, retest to verify how to reproduce it, then records it a bug report, sends the bug report to the developer, the developer fixes the bug, send the fix back to QA, it’s retested, then the bug report is closed.
•  Very Expensive – User finds bug, contacts customer service, customer service sends bug to QA, QA verifies the bug, creates a bug report, developer fixes bug, sends the fix to QA, QA verify bug is fixed, bug fix is redeployed to production.

How much the bug costs depends on how soon it’s discovered, the sooner it’s discovered, the less people touch it and the less it costs.  By writing tests developers are far more likely to find bugs sooner also nothing is more frustrating than having bugs reappear, manually retesting existing functionality takes time, and increases QA cost, also reduces the time QA has to find new bugs, and edge case bugs.  TDD inherently provides regression testing and can greatly reduce your QA time.  

Real world example

At one time I worked as a QA Engineer at a major printer company, a little over half my time was spent not only testing new functionality, but existing functionality as well, the rest of my time was spent sending bug reports to the developers, having the developers asking for clarification, verifying the bug was fixed, etc.    As much as it cost for me to test a printer, the cost of having a driver or even worse a firmware bug get released to the customer where astronomical.  By reducing the time I had to spend retesting and verifying bugs, I could spend more time looking for edge case bugs.

Something else to think about is unlike web development where you are only pushing code to your servers, having hardware in the hands of consumers with a bug requires the added cost of service representatives, service techs, etc.   

Reducing Costs by building on a well build foundation

TDD by it nature encourages good development practices, by breaking up chunks of code into more testable sections, you are turning them into more manageable pieces; this reduces the amount of time and effort required to update and maintain your application and greatly reducing the need for the dreaded rewrite. 

  

Ask any construction contractor what makes the biggest difference on a building remodel, and they are probably going to tell you “How well the original building was built”.  If the foundation isn't level or the walls aren't straight, it’s going to make his job that much harder having to compensate for the existing structure.  The same thing applies to software development, the less old code that needs to change to add new features, the less it costs to add new feature with the added bonus of the tests telling you where your changes affect the rest of the application.

Real world example

I worked on a project that was needed to replace how users authenticated; the user still entered a user name and password, but how they were verified need to be updated for security reasons.  By having the application broken up, all that needed to be changed is adding the new authentication code and changing one line in the existing code to implement the new functionality.

Using TDD isn't required to use these best practices, but trying to do TDD without using them is painful to next to impossible.