Archives
-
My short answer to "If no other engineering discipline does it first, why should I TDD?"
I agree Software Development by the truest form of the word, is in fact Engineering, but not all parallels can be made to its hardware counterparts, especially in its current state of maturity. We can build high amounts of complexity with few people in a very short period of time. All of which relies on other systems that are relatively unproven and unstable, it's hard to have a proper engineering process in these conditions.
This is why we need better code that can safely react to change. In my opinion, "better" code in statically typed languages is inherently easier to test. Its more isolated/abstracted and cohesive for its purpose.. and so are its supporting unit tests. This ensures small and large changes alike have minimum impact on the existing, unrelated code... without a nasty ripple effect.
TDD is just one ritual to writing code that I loosely term "better", it's definitely not an end-all. Clearly it's easy to assume writing more tests is the only correlation in less buggy software, but what the paper(s) don't show in numbers are the increased agility in the software process as every day brings a new change to the design that can be made more safely.
There is still a large human aspect to this whole process, and given short-term cost-benefit analysis', many times the code quality suffers; building rigid, new untested features that only cause growing pains and degrades the testing ritual that were initially put in place. That said, the cost-benefit analysis' do have to be made, and I wouldn't say that all bugs are worth fixing or can be fixed for a timely release. But you have to ask what the long-term cost is to a buggy system that becomes difficult to test or change without fear.