Have you ever experienced this? Vendors or teams of developers claim that being forced to write automated unit tests slows them down? How do you answer this? Even more importantly, how do you correct this misconception?

In my experience, this issue is particularly prevalent (a) with large consulting companies and (b) with inexperienced developers. Most of us have been on projects where bait-and-switch occurred with a large vendor – the A-team troops in for the vendor selection meetings; the project starts and suddenly the A-team moves on to the next procurement cycle and you are left with the “green team”. That’s “green” as in inexperienced, not “green” as in “efficient”.

So, scenario A results in scenario B and the true problem is … inexperienced and/or unprofessional developers!

I maintain that, if you hear claims that unit testing is slowing down a team, you should realize that you are dealing with inexperienced and/or unprofessional developers and act accordingly.

You have to ask what is the product that is trying to be achieved and does the vendor’s or developer’s idea of that product align with your organization’s view of that product? Here is a true example.

The “product” of one vendor with whom I worked on behalf of a client could be described as “the ability to bill for the next milestone payment”. The contract called for a milestone payment for “the completion of coding” with no criterion for quality included. Here was an example of the contract wording precipitating a problem in the execution of that contract. Naturally, any activity outside of strict coding, such as creation of automated unit tests, was frowned upon by both the vendor program manager and vendor account manager. Why? Because it delayed their product – being able to bill. It was very shortsighted because the result was incredibly poor performance in functional test – the worst example being that 83% (five out of every six) functional tests for one code drop failed upon first execution.

Interestingly, unit tests had to be delivered as part of the contract but the vendor, behind closed doors, talked the client into not requiring them until after functional test (and hence after the payment milestone). The client was not technically savvy, as you can no doubt tell. The unit tests were coded last – mostly by even more novice programmers than the developers of the feature under test – and ultimately delivered. Upon inspection, they were found to not provide proper coverage and, in many cases, did not actually test anything. The only way the test would have failed was if an exception occurred. The vendor fought against automated testing throughout the project even in the face of the evidence of functional test failures.

What was the overall result? For that one code drop, coding took about eight weeks, but then it took more than eight additional weeks to pass functional test. [Yes! This was a waterfall project … at least initially.]

It can be demonstrated that writing the automated tests first or in parallel actually speeds up the development cycle. So instead of taking 8 weeks to produce a fully tested and testable product, it took over twice that long, which caused a domino effect with all dependent projects having to re-plan to take into account the delay.

A bunch of untested line of codes that have “been finished” only because the developer clicked “Save” and went on to something else is not a valuable or a final product.

As the principal architect and technical lead, the product that I want has nothing whatsoever to do with billing cycles. It has everything to do with a finished, quality product. I want the product to be the programming, the tests which verified that programming, and any documentation needed to make that programming understandable and maintainable. That is the definition of a true product.

In Scrum this equates to the Definition of Done.

Scrum emanated from the Toyota Production System. How efficient do you think an automobile production line would be if components and assemblies were not tested before they were bolted on to a car or truck in its progress along the line? Not efficient at all. In fact, such a company would likely be out of business in the twinkling of an eye.

Quality is not injected into a product by some magic incantation during the QA cycle, it has to be built-in from the very beginning. Automated unit testing is a key ingredient of that quality.

Any developer who has any pride in their professional standing would want to ensure that the code he or she produced was guaranteed to the utmost of his/her ability to work correctly. I have worked with true professionals who have shared my mantra that “if someone else finds a bug in my code, I would consider that an insult”. However, with inexperienced developers and vendors pushing to get paid regardless of the quality of what they produce, this level of professionalism is often not present or has been beaten out of the developer culture.

Let’s stop trying to “quickie” development (rush through something without concern for quality) and produce true quality software products that will keep the assembly line flowing without costly stoppages.

Learn more about how to make automated unit testing a pillar of your software quality and do it in a real scrum environment in the Scrum Adventures CSD course.

–Ivan Biddles