More on Test Driven Development and Agile Ideologies

My current employer is a supporter of "big design up front" (BDUF). If you have been developing for a while you know this method, usually associated with waterfall development, to be a bunch of people sitting in a room thinking things up until it seems like a great idea. Well not exactly, but you get the point. A requirements document has been gathered - imagine a single document containing, supposedly, anything and everything that a client wants (HAH) - and developers and architects (who can even make the distinction any more) come up with the ENTIRE structure of the application. Let me repeat that, the ENTIRE structure of the application.

Now, how many times have you developed software for a company? Go on, raise those hands - ok, so I can't see them, but I know they are out there. Now, those of you that have ever worked with a client that HAS NEVER changed the requirements document after sign off can put their hands down. Not many hands should drop - hopefully. Requirements are just as dynamic as a business and should be treated as such. Okay, so what does any of this have to do with TDD?

One of the beauties of TDD is the flexibility (read creativity) it allows a developer to have while building an application. As my previous post mentions (the one back in Sept. of last year), starting with implementation can be a big eye opener when it comes to design. You see your application take shape and you can either continue along or change it as you go. And, because you are building tests first, when requirements change, there is no need to worry. The tests should catch any breaking modifications.

However, the true power of TDD seems to take shape when it is coupled with Agile methodologies. The Agile community focuses on developing working software through extensive customer collaboration from all members of the development team (agilealliance.com). What?

From what I can gather, Agile development is about small iterative cycles that end in a product being released to the customer. This means that components of the end product can be delivered well before the end product is complete, giving the customer a chance to see pieces of the application. What a powerful concept! The client has an opportunity to make changes as early and as often as they like. And because they are getting to see things early on, positive and negative feedback can be given before pieces become embedded into the application increasing modification costs - although if you are using TDD as it is intended, this coupling should not be a problem.