Institutional Knowledge

Anne Epstein has a great post about what she calls “Institutional Knowledge.” 

In her post, she focuses on the current economic situation, and the fallout from letting go of staff that has this institutional knowledge, but I think what she says can be more generally applied and understood.

You can read the original to see all the details, but she talks about an old Dodge Caravan she had, and the specific ‘quirky’ things she needed to do to get it to function properly in various situations (I can relate…I had an old Pontiac GrandSomethingOrOther that was similar…I've forgotten the details of everything but I remember in particular that the driver side window had some internal piece that was broken so that if you needed the window to stay up, you had to crank the manual thingy all the way to keep it from dropping into the door frame, and if you needed to roll down for a toll booth, you had to loosen it just a bit to get it to come down, but only a little, as you had to crank it back tight to keep it from dropping into the door frame…then you had to loosen it a bit and push up the window with your hand to close and then crank it back tight….or something like that…the fact that I don’t remember all the details proves the point, but I digress). 

Most anyone who has dealt with applications that have existed for any period of time knows how this applies.  End-users, in particular, learn to work around the bugs of an application by applying ‘tricks’ that allow them to get around the bugs and do what they need to do.  I remember an application that required you to click a button to perform an action, but for whatever reason that I no longer remember, you had to click the button twice.  The first time, it would fail with some cryptic error message, but the second time it would work.

In other cases, it involves the usage of particular terminology.  I worked on an application that had a fairly robust audit history system, where you could track who did what and when, but there was a background process that needed to run in order for the history to reflect accurately.  I was asked to look into a defect and see if it was because the “AuditDTS” didn’t run.  As a SQL guy, I knew that meant I should look at the DTS packages and see what was up, except that the background process had been changed to use something else (SQL Agent, I think) and it took me a while to figure this out. 

The aspect that is most prevalent for Institutional Knowledge is that it isn’t documented anywhere.  It resides in the minds of people.  And sometimes, those people no longer work for the organization.

Ideally, software is designed so that it is resilient to this, but the ideal is rarely met perfectly.  Learning the institutional knowledge surrounding an application is often just about as important as understanding the code itself.

posted on Saturday, August 29, 2009 7:26 PM Print
No comments posted yet.

Post Comment

Title *
Name *
Comment *  
Please add 6 and 8 and type the answer here: