Tuesday, August 23, 2011

Rediscovery (A Work-Related Post)


I came to a realization recently that I was wrong.

Ok, maybe that's not a surprise to anyone knows me.  Sure, I suppose that happens often.

But, it was about a specific thing that's bugged me for years.

I work for an organization that has some large and complex computer systems.  Over time, we've enhanced, modified and extended the purchased software for the purposes of meeting our business objectives.  And I don't just mean a single product - we have many different products that we use.  Some of which even have to talk to one another.

And they're owned by different groups who use different methodologies for updating them (waterfall, agile, whatever) and documenting them (golden docs, wiki, inline code) and maintaining them (don't, pay a vendor, update on a regular schedule, etc.).

But it always frustrated me how often we had to go back to the beginning, like an archaeologist and rediscover what the software did it, why it did it, and how it interoperated with other pieces of software.  And often, it was a really exhaustive and exhausting experience, and there was still opportunity to miss things and make mistakes.

But on my recent vacation, out running, I looked at all the paint markings on the street as I ran and I realized, that's exactly what this is.  Before any renovation can be done to an area that involves excavation, someone must come out and re-learn where all the of the utilities are.  On another recent run, I saw a survey crew measuring an intersection, distances, sight lines.  It was a city intersection and the surveyors worked for the city.  Didn't they just have some set of blueprints in the basement of a building somewhere that laid out that intersection?  For all the planning and work that goes into laying a new fiber optic line or widening an intersection, it all starts with rediscovering what's already there.

And so it occurred to me, perhaps software isn't all that different, except stuff is even more invisible.  You could try to keep meticulous records of every little change and every little dependency, but sometime, somewhere along the line, something changes and suddenly the documentation isn't completely accurate.

Trying to find all of the documentation and update it all every single time would be cost prohibitive.  And the guys writing the code don't want to write documentation.  And if you employ people just to do that, they're gonna be the first ones to go in a budget crunch anyhow.

So I came to the realization that my pursuit of perfect documentation - the ability to skip that entire part of the process - that's just untennable.  

And so that's why whenever a show like Leverage taps into a city planning office to get the blueprints of a building or the route of a steam tunnel, I just groan.

No comments: