The Importance of Documentation
A few days ago, Shimon, a programmer and developer, wrote about the importance of documentation. Many times during a project, I do not have time to create documentation for what I’m doing. Yesterday, I used a database I created over a year ago for the first time perhaps since I created it. I designed it to aid two coworkers with their work. When I used the database, I immediately noticed three things I could change that would make it much easier to use. As I worked on those things, I made several other adjustments that should benefit my coworkers. I spent a lot of time trying to remember why I set two fields up like I did and deconstructed and reconstructed them trying to get them to work as I hoped they would. I couldn’t figure out how to make them do what I want them to do. After tinkering with the database, I made notes on what I had done and why and what I tried that didn’t work. Next time, I won’t waste time fidgeting with those fields. I’m certain I repeated many things I tried when I initially set the database up.
I wondered why my coworkers hadn’t returned to ask me to add some of the features I added today. (I also wondered why I didn’t think of them when I put it together.) I forget sometimes that database users don’t always know what kinds of things might be possible with the database. And many of them just go in and use it and don’t think about things that would make data entry or searching easier.
You’d think I’d know better about documentation and these databases. A few years ago, a coworker designed a series of complex relational databases. She no longer works here. We’re often deconstructing the work she did to try to figure out why things work the way they do and whether we can make certain changes. I often wish she had given me notes about her work before she left, but it’s quite possible she didn’t make any.
