On the Importance of Documentation…

It seems that I keep inheriting old systems that provide a singular, albeit mission critical, function to their owners. In the majority of these cases, I have encountered numerous small applications that were designed to run in a standalone environment to solve a very narrow problem or set of problems. The person who supports the application – which is very often the same person that wrote the code behind it – eventually departs the company without documenting his/her work. Somehow these database apps keep chugging along for months or years until one day a tragedy occurs – like a folder being renamed or a mapped drive being deleted. My phone rings, and I step out of my database analyst role and into my Sherlock Holmes coat.

I’m sure you’ve all been there. A problem that should take you 30 minutes to fix actually costs you two days because you have to reverse engineer the environment to figure out what the programmer or database designer was thinking. These kind of things get me more irritated than a cowboy without a saddle on a hot summer day.

The Importance of Documentation

It’s not just for the sake of others that you document. I can’t tell you how many times I’ve looked over some of my own handiwork and wondered what I had been thinking when I designed a feature or configured a particular database object. With few exceptions, I almost always fall back on my documentation at some point, even for the most trivial of things.

So I put out the call to all of my fellow IT folks, database analysts/programmers/sysadmins/[insert your job role here]. Document, document, document. Even if you’re sure no one will ever need it, document. If you are creating an ETL database that you plan to delete in 90 days, document. If you write a function that’s more than three lines long, document. Your successors will thank you for it. You might even save your own job some day!