Good vs. poor documentation: Don’t be ‘that guy’
A well organized and well documented system, complete with commentary within your code, can only help you and your fellow developers and programmers.
Over the years we have all had to modify, repair, debug, and otherwise live with someone else’s code. The platforms vary, but the challenges remain the same—the biggest of which is, “What in #@$! was this guy thinking?!” Looking at that single—sometimes painful and often confusing—question leaves us wondering how it happened in the first place.
More often than not, we find ourselves in this perplexing situation because the documentation has become separated from the program. This can happen for various reasons:
– The equipment has changed hands several times, misplacing information
– Someone saw this as an opportunity to insure continued employment by being the ‘go to’ guy
– The dog ate it
– It was never developed because the intent was “self-evident to anyone who knows what they’re doing”
– The information was intentionally stripped.
These are just a few of the many reasons. We as developers and programmers can’t do much about the first two; this is simply a fact of life and is typically caused by our end-user. Meanwhile, that pesky dog has been a haunting presence since grade school and will probably never die. But it is the last two reasons that are well within our control.
When we put a program or project together it is critical to truly complete the job. A big part of that complete job is a well organized, well documented, and maintainable system. The more tightly bound this information is with the actual code and configuration, the better. The more thought-out and organized the code, the better. It’s important to keep in mind that no matter what, you will probably NOT be the only person who will have to work with the code or configuration. There is also the issue of remembering what you meant as well. Believe it or not, the documentation and commentary starts before the first line of code is generated.
Code and configuration commentary does not have to be a literary masterpiece. You’re not being graded on grammar and spelling. The most important point is to simply leave the explanation of what was done and why. Make the in code commentary sections easily maintainable, this encourages others to follow your lead. Recent development environments aid in the documentation process by pulling that information forward through various construct use, provided the commentary is supplied from the beginning.
To those people who intentionally strip comments and don’t supply documentation, there’s a “special place” set aside for you. Unless the deliverable was only specified to be a compiled executable with no source code, there is no excuse. Somebody somewhere will have to deal with the mess that you leave behind. You’re only hope is that voodoo dolls don’t work.
In the end nothing anyone says or does can force you to realize the benefits of good documentation. We all appreciate well documented code and configurations. This is in the end a learned habit. There is only one real learning experience that will change your ways and that is digging around in a program and cursing the original developer, only to realize that ‘that guy’ was you!
Don’t be ‘that guy.’
This post was written by Jeff Monforton. Jeff is a Senior Engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.