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 Converter

As a follow-up to my previous post, I'm working on an app to convert Fitnesse content.txt files into NUnit tests. I'll post the files and anything interesting I find along the way.

My basic approach is going to be to grap the tables and then use reflection to interogate the underlying classes that the fixtures exercise to generate tests.

We have about 10K Fitnesse tables, so the timeline and overhead for a manual conversion is fairly overwhelming, which justifies the time to research an automated approach.

A painful pseudo-discussion

I came across this little informational post on code inspections. Seems like a little bit more of a formalized process to how we do our current code reviews. I like the encouragement of getting everyone involved in the process though, which is something I fell is missing from most code reviews. No matter how much you try to get everyone to participate, it turns into more of a presentation by the senior team to the rest of the developers. One section that really caught my eye, though:

Motley: That still looks pretty formal and heavy to me! Just the fact that you have a diagram describing all the steps is a little scary. I'm worried this practice is going to suck up a lot of time.

Maven: Ah, don't be afraid. The process is actually quite simple and not unlike other code reviews. It's just a little more structured with a couple of key practices to ensure that reviewers are highly effective. First we start with planning.

Motley: Yeah, the process is so complicated I bet you need a plan just to pull it off!

We have someone at work you is almost exactly like the antagonist in this little one act play and I can't scream loudly enough how much of a poison pill this person is to the team and morale. If you have someone around like this, I would highly recommend doing whatever you can to keep them at arms length from your projects. True Believer Agilista's can be dangerous.

Red Meat

When is comes to what an application is and how developers perceive it, what is the Red Meat? What is it that motivates a developer to WANT to work on that particular functionality? Usually when working on requirements, if the phrase "what is the meat of it" is motioned, it's usually in reference to some critical piece of the functionality. But I think more often that not, that is the mean from product or marketing's perspective and that rarely translates to what the developer will perceive as "meaty".

No, I think that from a developers perspective, the requirements of an application are no more that the skeletal structure, mere bones that give the meat something to hang on. Maybe there is some tasty marrow buried deep inside, but for the most part is something to get around or toss aside.

How then to get beyond simple requirements of functionality and get a developer to see the possible meat to be added to the bone? The easiest way seems to be to tie the functionality to some new technology that's worth exploring. 10 years ago, the key word would have been XML. These days it's probably something like AJAX or SOA/SaaS.

In the long term, using bleeding edge technology as a motivator fro developers will create a hodge-podge application with mixed technologies that are only half implemented and have no hope of ever working together, until the next great tech comes along and provides an excuse for writing some part of the app that's using a now antiquated technology poorly.

No, the key falls more in letting a developer create the functionality AND tie it into some pet project as well. No doubt there are lots of tools that your project needs but has been placed on the back burner as low priority. One of these tools may be advocated by a developer on your team and it may tie closely with the functionality that you are looking to add to your project. If so, you are lucky. Let your developer create the tool and integrate with the functionality. You now have a new tool, new functionality, and a happy developer. If not, don't fret. Just think about your team and your environment. There must be things that developers WANT to do that relate to what NEEDS to be done. Try hedging the NEED to do within what the developer wants to do.

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.

Managing developers is like herding cats

Everyone has heard this phrase (or some variation of it) at least once. It is usually spoken after some "failure" occurs, usually related to some delivery date being postponed.

Oh so long ago, I read the phrase "A pack, not a herd" opined over at Instapundit, but it was only until recently that I connected it to the realm of software development. And the followup question that's never asked, and may be very important is "Why would you want to herd cats?"

Why would you want to take away from a species it's best ability, and then still keep it around thinking it could offer some skill that's useful to you?

Unfortunately, the question still remains: If you have a bunch of cats, and you have a bunch of vermin (bugs, new features, etc.) how do you get you pack to rid you of your problem?

Exploring that dilemma will be this blog. And some coding items as well.