@George - I’ve done my share of contracting as well, and though the code-ownership is usually short term, you have to have that ownership while you’re writing it because somebody is going to maintain this system after you leave. That somebody could be you at a later date, as well. To operate under the assumption that, “I’m just here a short time, I’ll hack in whatever I need,” is unprofessional.

@jak, I’d argue that TDD is a strong side of the maintenance of a system. You’ve got a strong suite of tests to maintain against, the “safety net” to know you’re not doing damage elsewhere. The practice of TDD is for design, but the result of it does make maintaining an app much easier.

They are provided also by … BDD, POUT, Automated Integration testing and by a good QA department and process

The benefits of TDD are little to do with long term maintenance, but to do with driving out a design in code. Testing is not the important part of TDD … Design is.

That said, I could and would argue that TDD is not a great way of driving out a design for most scenarios, and BDD or even just spiking, would provide a faster and leaner solution, and more long term value

You’ve been kicked (a good thing) - Trackback from DotNetKicks.com…

As a consultant myself, I have to take pride in my work and be disciplined enough to not create a mess for other people to deal with. That’s not something that I want attached to my reputation. :)

TDD helps me quite a bit while I’m developing the application — there is plenty of short term benefit to it. I still need to know that my code is working and that I’m not going to break things.