Wheaties Syndrome

Every group of decent enough size always seems to have at least one person who looks at all the great tools out there, especially those used or pushed by the thought leaders, and will scream to anyone who will listen that if you only start to use these tools, it will solve all the problems being encountered. They probably ate Wheaties as a child thinking they would grow up to be a great baseball player, too. This applies to methodologies, too. If you makes big mistakes because you didn't understand how to implement a practice well, how could you have known that this practice would solve your problems? Coming up with new rules that make the practice or tool "work well" simply smells of the tool or practice being flawed of incomplete and your own talents making it work.

One may think that the unasked question is "Why would this be beneficial?" or "How does this solve our problem?", but I've started to hit on the big one being "Why did this work for them and how are we different?" This helps to highlight that tools are specific things...that the hammer won't get the brick secured to the other brick very well. Too often, as well, methodologies and tools are mashed-up, with one become tightly linked with the other. Agile needs Fitnesse or TDD, for example. (No! Automated testing allows for more complicated code to be developed and increases productivity. Any productivity gains Agile gets credited with is an industry glow effect from TDD)

I've found that the best way to minimize the flare-ups of Wheaties Syndrome is to ask for separation of tools and methodologies. Explain why this method would work for us with out the tool. Explain why this tool will work for us without the method. More often than not, it's the right tool used correctly that will provide the most benefit. Methodologies are the way that consultants and book writers latch onto the tool and try to steal the benefits (see also: Linux).

Fitnesse Sux (but you knew that already)

About two years ago we began the shift to Agile Development. Part of that shift was using Fitnesse as a comlimentary testing platform to the already exiting test library written using NUnit. This provoked many time wasting debates trying to answer the questions "What is a Unit Test?" and "What is an Acceptence Test?" when the real question is "Does it matter?"

Additionally, Fitnesse is seriously not ready to be a test platform for .NET...it is still primarily a Java thang for socialists (redundant?). And the TDD/Agile thing is still horribly unresolved for issues of working with code from a legacy system and with Product Managers used to old guard ways who refuse to actually write tests.

(We've found that even though Development is more that willing to go with Agile, trying to get any other department in the company to do their "Agile part" is like trying to get a dog to chase the LASER pointer: sure he sees it, but it doesn't look like any duck he's ever seen.)

So Developments issue has been: we've got a 500K+ line, multi-languange code base that hasn't been designed for Fitnesse fixtures, no one else in the company is willing or able to write tests in Fitnesse besides Development, and syncing code and tests in a Continuous Build environment is next to impossible and one of the most common source of failed builds.

So we've finally made the decision to ditch Fitnesse and move back to 100% NUnit tests. Orcas may change that with better integrated testing regimines, but that still doesn't provide any ticks in the plus column for Fitnesse.