Thursday, October 25, 2007

You want a what, now?

I guess pretty much every programmer in the world goes through this experience in their lifetime when they are presented with a project that is so ill-defined, so nebulous that it twists your mind inside out as you try and fathom exactly what it is that you're being asked to do. You poke and prod at the amorphous blob that is your project hoping that, either by skill or by chance, you can coax it into revealing to you some of its actual features or some of its internal machinery. It's like looking out an icy window: you can tell that there's stuff out there, maybe you can even discern some of the colors and shapes, but the reality of what's outside may in no way correspond to what you thought you saw through the frozen glass.

As such, how do you begin? One approach would be to say, "Well, all I can see is a green blob so I'm just going to make some software that does green blob-like stuff. I can always change it later when I get a clearer picture of what's needed." This approach appeals to the part of me that doesn't want to waste my time on doing complex things that may very well be wrong. But there's a part of me that really doesn't like doing simple things that I know for a fact are going to be wrong. I know that I'm not really looking at a green blob ... it's probably really a stalk of broccoli, something with defined structure and intricate detail. But what happens if I go through all the work to deal with broccoli and it turns out that I was really looking at asparagus?

So, food-related metaphors aside, I'm at this frustrating point of not knowing quite enough about what I need to know, yet still feeling like I need to make some sort of step forward. I keep talking with other people to get their ideas and it's all still very blurry and green blob-like in their minds too. For those of my old coworkers that make it this far into my ramblings, it sounds like I'm going to be basically implementing metadata, but with a few extra twists. Metadata was, in my mind, easily one of the few most complicated areas of the code that I worked with. Maybe it had to do with the way the code was written, or maybe it was just that it was a complex, hard-to-understand beast of a problem. Either way, I'm going to get my chance to try and replicate it and, hopefully, understand it better this time around.