Testing at the end? You can't be serious

I noticed a link to this Waterfall Conference that also a keynote called "Put Testing Where It Belongs-- At The End." I'm in awe that anyone would say something that, to me at least, is so fundamentally stupid. And yeah, I know this is a joke, but people out there actually think this way.

Let me start that I don't get into religious arguments, whether it be about New vs. Old Testament, Linux vs. Windows or Agile vs. Everything Else. Those discussions just aren't interesting to me. However, the bigger an application gets, and the more people involved, the more I feel that test-driven development is absolutely essential to building something that works. I honestly could care less about most of the tenants of XP or agile, but TDD has saved my life.

And I do get why people are skeptical. The gig I just started has a lot of people skeptical about unit testing in general, mostly because it's considered an afterthought. It really is a cultural shift. People think it's more work, but no one can ever ask the fundamental question, "How do you know the change you made didn't break something you haven't thought about?"

When I first started a gig at Big Ass Auto Insurance® as a consultant, they were buying into everything agile. The paired programming thing annoyed me, and I hated it, but the test-driven stuff fascinated me. Here you could fire off the tests from the entire solution, testing tens of thousands of lines of code, and if something you did broke something, you knew about it. In fact, if you didn't run the tests, the continuous build process would tell you that something was broken. Without this testing facility in place, you had to rely on poor metrics like a lack of compile errors, peer reviews that assume someone in the room knows the rest of the system, etc.

This doesn't even get into the trouble that is test bias. You can't write unbiased test code if you've already written the code. You're too close to it. While unit testing assumes you're doing thorough tests and driving the design of your classes from those tests, it still gives you confidence your stuff works.

Now regarding the waterfall methodology, most of the instances where I've been around it, it fails, or delivers low quality software. Again, I'm not religious about any one methodology, but anyone who has written one line of code knows that stuff comes up, and specifications frequently have to change. I don't know why people try to fight that. Keep the stakeholders involved at all times and the change management is tolerable. That's one of the things I like about a more iterative process, is that you can refactor to a place that you get what you want and need, not what you thought three months ago you wanted and needed.


  • Jeff, the web site for the waterfall conference is a joke.

  • Jeff, are you serious with this site?

  • Please tell who you've worked with that work this way. I want to avoid them like the plague :)

  • Still, that "Super Model Driven Architecture" keynote looks interesting :)

  • However misplaced the reference to http://waterfall2006.com, it is hilarious! It's nothing but a joke. One indication is the conference date: Apr-1st-2006.

    No one needs to sell me TDD but the reference has gotten me the laugh of my day. Thanks Jeff

  • Sadly, I work at such a company that believes in "Test Driven Deployment" rather than "Test Driven Development" (or Design).

    The project managers have "successfully" completed several horrifically expensive (and late) projects and continue to thrive in their perception of Waterfall as a successful project management.

    The funny/sad part is that a couple weeks ago I sent-out that URL (playing it straight) to the project management team, and got some head-nodding over the topics and such. However, they didnt quite see the need to attend a conference on a topic that they already knew so well. :P


    Thus part of the reason for my recent blog post asking someone to hire me away from there.


Comments have been disabled for this content.