BDUF was especially interesting when I heard Peter Provost and Billy Hollis speak on this topic during their presentations at the PnP Summit last year. Both made points that I could definitely relate to. You see the (embarrassing) thing about this post is that I didn’t know what BDUF was, and was living it everyday, but waterfall was supposed to be OK? I never heard anyone say BDUF until I hooked up with .NET a few years ago (I wrote my first line in December of 2003), even having done a few tours with Java (1.1) and VB6/ASP. Instead it was a place I had spent many years living in, remember The Truman Show, like that.
I was driving home today after a very long day of WCF unit testing for a current project I’m helping with and realized why the day was so long. I wanted everything to work like it was a BDUF project. I thought everything I was working against in the DAL was done, that’s what you finish first, right? A very awesome coder who is our technical leader is cranking out some awesome NHibernate bits for our DAL. But we’re using Agile to make this solution happen. My first sprint planning meeting I was biting my tongue to keep from asking BDUF questions, this was the first sign that this BDUF was very deeply engrained in this developer’s habits and thoughts. Maybe I’m making it sound worse than it is. But having done so much BDUF development which never really had a great design to begin always looked like something else, and didn’t really hit the target, budget, or timeline. I’ll stop there, I won’t throw anyone under the bus – teams succeed and fail together.
I thought it was worth throwing out a few words on the topic since I’m really enjoying the Agile development and the community is by and large running with it (slowly) as well. But, to a point that Billy Hollis made, waterfall development has a place in some
shops projects. He gave an example on building rule-based systems where the rules needed to be defined before the system construction could start. And in that example, his team was successful and the customer was happy with the result.
However, in my experiences, I’ve seen and been a part of the teams that left a wake of poorly written code that couldn’t be maintained. How could this happen? I think that some folks believe that it’s far less expensive to support a system than to (re)build it. I heard Michael Feathers discussing a Strangler System on Hanselminutes. I can see this approach working for some of those systems, however the date on the article is June 2004. Just like Truman I was fast asleep and no one was trying to wake me up back then. If the community was thinking about Strangler Systems, we were probably aware that the waterfall might not be a great thing.
This sprint is going very well so far and it’s still early. The customers are asking great questions, providing awesome feedback during the cooldowns – and we are not reacting, but we are responding. And my part of the sprint will be going even better once I get back to my desk and comment out the code that really shouldn’t have been written in the first place. Refactoring code that doesn’t even serve a need yet, geez! But with BDUF you are always in that 9th inning push to clean the bases and bring everything home. Like Ted Williams, I’ll just try to get my three hits each game, win or lose. Someday I’ll get to Fiji, the airfare in my part of the division is getting cheaper by the sprint.