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).

Herds Graze

Herds plod along, eating whatever they happen upon (or is left out for them)...sometimes heading over to the watering hole. Packs seek out their food, catch it, and consume it totally.

Which description most accurately describes a development team? Which one should?

Part of what seems to stall most teams and produce sub-standard product littered with bugs and inefficiencies seems to most often come from a company culture that defines the work to be done and the time frames the work is to be completed in outside of the development group. This produces a feeling of exclusion and leads to phrases like "They never let me clean up the code/re-factor/work on anything cool."

Agile takes some steps to help fix this but, as I've mentioned before, if the rest of the company doesn't buy into the process nothing will come of it. If you can get only one thing out of Agile, make sure it is the concept of estimating little bits of the work to be done. This one little thing can be the first stepping stone in getting your development department to start hunting prey efficiently.

Once you have estimating in your control, the next step is to define an anatomy of an estimate. I've worked to create a multi-part plan for each story card to be completed that included improving the app, giving the developer some buy-in and a sense of ownership. What comprises an estimate are:

1. Building Tests (TDD)
2. Coding Feature
3. Increasing Test Coverage in area (NCover, NUnit)
4. Fixing Bugs
5. Re-factoring
6. Buffer
7. Round-Up

Each of these steps build on each other over time, and there is some limiting that must be put in, lest the entire application be in a constant state or re-factor. Simply put the total work or 3 -5 should not exceed the work in 1 and 2. This means on a first pass in an area, maybe only #3 will be done. Next passes may include #4, etc. The order is also important. An area should not be re-factored until it is close to bug free. Bugs should not be fixed unless there is adequate test coverage in the area to be fixed.

This begins to take some of the scope of work to be done away from Product Manamement and Business Analists and gives the individual developers some discretion in what they will be working on. They will no longer be eating what they come upon, but activly seeking prey.

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.