An interesting essay on Test Driven Development [TDD] which links to an empirical study [pdf] on the effectiveness of TDD in projects and its impact on quality and development speed. The abstract included:

Based on the findings of the existing studies, it can be concluded that TDD seems to improve software quality, especially when employed in an industrial context.

Industrial there seems to mean out in the real world of development at corporations and software shops. Of the thirteen studies that were looked at in this study only three were in a production environment, the rest were academic or computer science students or the voluntary participation of professional developers. Which limits the usefulness of the results. However of the industrial studies:

It is especially significant that all industrial case studies reported considerably reduced defect rates, as much as 40 to 50 % less. The productivity effects were not that obvious: ... report TDD significantly decreasing the lead-time while the ... other ... study shows TDD to have no difference or only slight impact to the developer productivity.

One of the benefits of TDD is that it espouses 100% test coverage. If you are doing tests first and API second then you are guaranteed to have 100% test coverage of your code which I do not doubt reduces defect rates. Unit testing is pretty powerful when done well and when it covers the cyclomatic complexity of code.

I personally do not use TDD, I prefer to muck around with the code first and get something in place first before locking it down with unit tests. I agree with the original essay that TDD tends to freeze the API in place to early. Some freedom is needed to 'feel out' the design of the code in my not so humble opinion.

The counter argument is that you can refactor with confidence once there is 100% coverage in place and then improve the design under the umbrella of passing tests.

This article has a look at whether TDD is faster than non-unit tested code in completing features. It seems it is slower but has far lower bug rates;

Research done by IBM and Microsoft indicates that TDD teams took 15-35% longer than teams using more traditional development practices. However, the bug density of projects developed using TDD decreased 40-90% relative to similar projects that did not practice TDD.

The article did not have any information on how much time was saved in support of the product, or by the lower bug rate that TDD allowed. Skimping tests to get code out faster in my opinion is a false economy.

I am not friends with JIRA. It introduces the most stress into my life and takes away the ability for me to control my day and work on things that need to be done. Like a manager or a meeting, it is an intrusive piece of software that is a constant distraction. Worse, anything that appears on it often generates a flurry of emails from different interested parties as the normal escalation rates occur.

As I said, JIRA and I have a relationship, but it is a not a good one, we are not friends.

Since the flow of bugs coming in is a major source of stress, intrusion, distraction and impedance; there is no incentive for me to skimp on unit tests. If I do, and get a feature out earlier, it will only end in a flurry of bugs coming through JIRA which I consider more stressful than completing a feature and putting 100% unit testing and functional testing coverage over.

Who benefits by a feature going out earlier but getting stuck in QA and generating more bugs? No-one. It is a false economy to argue for that. Worse, it is more stressful for the engineers to be facing several blocker bugs, criticals and even majors. All it takes is someone to see that list and make a flippant comment; "Yeh we need that trivial bug for go-live." It is how death marches perpetuate.

At the previous place I worked. It was expected that a large project of three to six months in length, would generate 800 to 1,000 bugs. They did not do test driven development. In fact there were no tests on anything at all. Most of the code was in javascript and test harnesses were being introduced, but it was all untested code.

All those 800 to 1,000 bugs would be assigned to me first. I would regress it, check it was real, add some more definition, add stack traces etc, and then assign the bug to another engineer. I hated it. It was stressful and simultaneously soul destroying. I left that job because of the effect that style of development was having on me.

When I went to the current place I started by unit testing the code. It was how I learnt the code base. They didn't have any unit tests either but the culture changed quickly to one of 100% test coverage both unit tests and functional. It was the only way we could guarantee quality and keep JIRA off our backs.

We just went through end to end testing before go live in which there was two large development operations in two EARs. They are huge codebases that had 0% coverage prior to 18 months ago. Of the end to end testing, we had three code base bugs against us. It was awesome. I was so proud of the engineers.

More importantly I went from a work place that would see several hundred bugs found in end to end testing, to one that had three. I wonder why my stress is lower and why I enjoy working here. It is because the code base is of higher quality and because it is fully unit tested.

I interact with JIRA less because of it, and am supremely happy for it. It is all about incentives, and I don't have any incentive for myself or the other engineers to crimp on tests and consequently produce low quality code.

We don't do TDD. We generally write a method or a few methods first and then put unit tests over the top. We still have a lot of the codebase that does not have test coverage, so each time we touch a method without coverage we write unit tests for it. We also cover our features with functional tests that hit the codebase as a system and create inputs and then test the output.

One of the large changes from this methodology is that we had to make the system testable first. So the outputs were testable. This meant passing back something that could be used by the functional tests to get and check up in the database and other systems that the state had been properly changed.

That is a discipline that is not fully understood by architects and engineers that do not do full test coverage on their code. So it can be frustrating at times to be faced with systems that are non-testable and finding some way to get around them to ensure they are fully testable.