stealth evolutionary projects

I’ve threatened to write about this a few times, and here’s my first take on the topic. I know this diverges from my usual policy of not writing about work, but I’m hoping to be general enough to be useful.

One often sees projects, particularly IT projects, that are a Really. Big. Deal. As in months (years?!) of meetings, lots of angst, big expectations that can probably never be met, even by the best system in the known universe.

Conversely, these last few years I’ve had an opportunity to work on projects to which not much attention was paid, and for which the expectations are relatively low. The most interesting, to me, are the ones that have evolved over time. Here’s two examples, for which the names have been changed to protect the innocent:

Project A is an information service, designed to replace a much-maligned, but also much-loved, paper resource. It has been taken on by a department as a Project. There are Meetings and Presentations. There is an intern, who suffers muchly. (This is how I came in on the thing, through the intern; those who know me off-blog will know the project from these few sentences.) It has taken a couple of years in different iterations to get even as far as an intern with ideas knocking on my door. We get it done, but it’s a rough stretch for both of us.

Project B is almost a CMS, which I started on by creating a simplistic template to make redesigns easier. A few years later tacked a database onto it to keep track of a few extra things. Then it occured to me that I could use that same information to request updates from people who actually know things. A couple of scripts and a cron job later, and I have a way of automagically getting page updates. The next step will probably tie the navigation into the database. But I don’t know for sure, because it’s still evolving.

Actually, the funny thing about Project A is that it’s transmogrified into an evolving stealth project. Once the basic bits were running, I figured out new things to do with it. I’ve never asked for permission, nor have I needed forgiveness. Somebody has an idea, I think it generalizes and can be done, and I slide it in.

Is it an open-source ethos? I see something broken, or something that could be better, and I start futzing, and eventually the futzing either grows into a system (ala templating) or I realize I need something entirely different. (The danger, of course, is poor documentation. In the long run, the key is to have a cohort in these adventures.)

Here’s my take on it philosophically: when something becomes a Project, it gets a name. The name comes to identify what it is and what it does. Names, of course, are powerful; names are also confusing, because of the mental pictures in our heads. Soon nobody knows what the Project is supposed to do, or what’s involved in actually doing it, or why they should even care.

Futzing? Stealth projects? Evolving programs? No name, no expectation, no confusion. Stuff just happens. Learning by doing; trying, failing (or partially succeeding), and trying again. That’s what it amounts to, and I think it works for me.

I don’t know if I’ve really expressed it properly; I may give this another go again sometime later, but I wanted to get it out now while I was actively thinking about it.

(As an aside, this is where I’m at with my long-suffering Odd Review/Media Diet project. I’ve got it working and now I’m playing with features and details.)