A few years ago, I had to defend to an executive the extra cost of implementing unit tests in a project compared to the return it would give. This was during an architecture board meeting and he pretty much caught me off guard, so I had to come up with something really quickly.
Luckily I remembered an article I read a long time ago that compared Japanese and English players in the automotive industry. Overall during the sixties and seventies (maybe even eighties), Japanese built cars were of a higher quality than the cars built in the Western world. The amount of 'broken' cars produced by American or European were incredibly high compared to what Japan produced. Those cars could not be sold as is and had to be taken apart and repaired while they haven't even left the factory, which was very expensive!
To explain unit testing to the executive, I told him the above story. Then I elaborated on the way Toyota solves this by implementing something similar to 'unit tests' to test the quality of the most recent addition in the intermediate product (i.e. unfinished car). They prefer to stop the process and rather get the quality right the first time than to take apart the car at the end of the line for reparation, which is obviously very costly. This saved Toyota a lot of money and made them much more productive at the same time.
By comparing this to a more easy to understand case and showing the financial benefit using unit tests had, the executive was immediately convinced. I didn't even have to give figures, because it made so much sense. He didn't know that Toyota did this and was even surprised to hear it.
I never found back the article, but I did find a book on the Toyota way (http://www.amazon.co.uk/Toyota-Way-Management-Principles-Manufacturer/dp/0071392319/) which elaborates more on the case above and also elaborates on how Toyota works in general, which is also a very interesting read. They might have to re-read it themselves considering the recent events/recalls ;-).
I never found back the article, but I did find a book on the Toyota way (http://www.amazon.co.uk/Toyota-Way-Management-Principles-Manufacturer/dp/0071392319/) which elaborates more on the case above and also elaborates on how Toyota works in general, which is also a very interesting read. They might have to re-read it themselves considering the recent events/recalls ;-).
Principle 5 is the one I am referring to and here is a summary of that principle:
Principle 5. Build a culture of stopping to fix problems, to get quality right the first time.
- Quality for the customer drives your value proposition.
- Use all the modern quality assurance methods available.
- Build into your equipment the capability of detecting problems and stopping itself. Develop a visual system to alert team or project leaders that a machine or process needs assistance. Jidoka (machines with human intelligence) is the foundation for “building in” quality.
- Build into your organization support systems to quickly solve problems and put in place countermeasures.
- Build into your culture the philosophy of stopping or slowing down to get quality right the first time to enhance productivity in the long run.
You might argue that Toyota was rather doing integration tests instead of unit tests, but for an executive this is pretty much the same. Hope this helps whenever you have to defend unit testing in your company!
This is a great point. Of course, the costs of TDD can be very high and difficult for many which is why a framework, like Typemock Isolator can be very helpful in enterprise environments.
ReplyDeleteI am not going to delete your post for being a 'hidden advertisement', since I think Typemock can indeed be interesting for some people.
ReplyDeleteI just want to add a pointer to alternatives though for completeness:
For Java:
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#Java
For .NET:
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#.NET_programming_languages
And now you have Moles which is free from Microsoft so you don't need TypeMock anymore.
ReplyDeletehttp://research.microsoft.com/en-us/projects/moles/