This one is from Tim Barcz over at Devilicio.us.
A few weeks ago I got some evil glares when I suggested at our .NET user group meeting that in enterprise systems that you don't have time not to test. It's a common hurdle for those new to testing to say, "I don't have time to write tests." Let's face it, we're all busy, that excuse is tired. As an agile and lean practitioner I seek out ways to improve velocity and reduce waste, not take my already busy schedule and cram in another tool for the sake of another tool. While writing tests does slow me down, it brings on tortoise like speed, which I would argue is a good thing. Writing unit tests is one tool that provide me the ability to keep a more consistent velocity over the course of development. Without tests I can surely write things faster, the problem arises as the codebase grows and each new feature or fix takes increasingly more time. Eventually, even simple requests become arduous to implement. Slowly you see your velocity come to a crawl.
We're dealing with this very problem where I work now. We reached the point where "even simple requests become arduous to implement". But we are well aware of the traps that our predecessors fell into, one being that they gave up on unit testing under schedule pressure. All that technical debt built up to the point that we are now declaring technical bankruptcy.
What does that mean? Well, basically we're starting from scratch. The original code wasn't built to be unit tested even though the original programmers wanted to do testing and even started to try. But classes were highly coupled which made testing arduous. And, unfortunately, instead of recognizing this as a smell, they pushed onward, declaring unit testing too complicated and time consuming.
So now it's our job to level out the graph and make the transition to a tortoise, pumping out a steady stream of reliable, well factored and unit tested code.