Cart before the Horse

Sometimes you can't avoid it. You just can't write featureA until you at least define featureB. It would sure be nice if everything was separate, but on occasion, it's unavoidable.

For example, consider a situation where you're interfacing with an external service. Say this external service accepts requests to do some work and also provides feedback on work that is either completed, or in process. Classic consumer/producer type stuff. Your typical remote work queue.

But, what if you're responsible for both of these systems? It's pretty hard to write the interface that calls the external service if you don't know what the external service will need to complete it's work. At the same time, it's difficult to write the external service if you don't know what work is to be performed. Until you know what feedback is required by your system, or what data your system will have to reference the external system, it's pretty difficult to know how you'll gather and return the feedback.

Cart before the Horse. You need to know at least a little bit about each system in order to even abstract out the parts that are generic. Until you know what data each system will have, and what each system needs in order to do it's work, you can't create the protocol that they'll use to talk to each other. And until you do that, trying to define one side of the equation is pretty much guesswork.

A good post on clean coding

Here's a great post on keeping code clean. Some PHP guys say Smarty isn't useful; maybe that's why there's so much PHP code that sucks to work with.

Building just what you need, even when you know it's wrong

I just completed some functionality that I know is incomplete. Sure, all the tests pass, but I know there are other tests that could be written. But since we don't have time to make the tests pass, I'm just not writing them.

The functionality basically merges values into a document. Think "mail merge" type functionality or smarty-style tags. The current implementation will work for all of the "official" user stories we have documented. However, I can think of certain situations where, especially if escaping is involved, the merged output will not be what is intended.

So, should the time be spent now to make sure that any possible input can be handled? Or do we stick with something that may handle all of our needs, and add tests only when we run into situations where a customer need additional functionality?

Regardless of the "right" answer, we're moving on . . .

My love and hatred of Fitnesse

I honestly can't remember how I survived without Fitnesse. What a marvelous tool!

Fitnesse provides regression and intergration testing of our backend api, acceptance testing that is clearly understandable to non-programmers (even managers can understand it) and specs for developers. It allows us to put our datastores into a known state before tests run without having to expose the functionality through the api. Truly, exactly what the doctor ordered.

But there's a dark side to Fitnesse too. And it goes beyond the fact that, as a wiki, it's easy to get a big mess of tests with very little organization. After using Fitnesse for over 2 years, we've been able to rangle in the mess and figure out a good organizational strategy.

The biggest problem we're facing now is a limited number of people that can write quality tests. In fact, the only one who puts any serious time into writing tests is . . . me! Sure our project manager spends time putting in user stories, but these are little more than "items should be able to be deleted" type entries. The act of converting that into actual executable tables falls on my shoulders.

Perhaps it's because I'm too controlling, or perhaps it's because I know that having quality tests ready to go means that the team will always have well defined work to complete. I wonder if I should try offloading some of the testing onto other developers (the only ones who have any chance of creating quality tests), or if I should keep them working on making the tests pass.