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.
introspection technology entertainment-books and magazines sift work diet/exercise video funny cars worth repeating Christianity/church ideas and creativity bad company transit and development advertising / branding / marketing email music unclutter random food entertainment-television Google by-week 750 Starbucks 120 family #blogaday cool coffee parenting L.A. architecture entertainment-movies environment leadership Christmas Apple Seattle autism atad entertainment photos art and design weather politics by-year geography identity rain social home improvement travel Amazon Disney by-month money snow charity dream Lego how to vacation awful conference crime simplify children AT&T LOST news sports education fashion clueless improvement links no-bars-blog 2013 NASA NBC GTD fail good company holiday nostalgia trust30 war 2014 empowerment journalism legal picky power powerless quoted Cuba Lori cord-cutting focus great day inspirational radio Federal Way McDonalds Rachel Tacoma medical videoblog Boeing Microsoft Wal*mart art buffy conspiracy culture laundry sellout web 2015 PLU customer service fool review robots and drones