TDD has been around a while (a while in computer time...) and is really a formalization of unit-testing. It is something that needs to be taken into account and budgeted for, IMO. If you don't budget time for it then you can't track it and, as with anything else that isn't budgeted for, it's the first thing to get dropped, as you say. I'd argue that if you're not budgeting for it, you're not likely to get the full potential out of it.
It's not necessarily an intuitive process, and to a certain extent it's an art. It's hard to get right. So, ramp-up and learning-curve needs to be accounted for in some teams--without a budget for TDD there's no budget for learning it either. This leads to doing it incorrectly, which can lead to complete distrust of the concept. On Fri, 4 Jan 2008 17:39:21 +0000, Paul Cowan <[EMAIL PROTECTED]> wrote: >TDD is very much in vogue at the minute and I do see the benefits but there is a real maintenance overhead that should not be underestimated. > >That is multiplied with continuous integration. > >When timescales slip they are usually the first things to go. > =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
