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.

12/17/2013


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.



Anonymous , 12/18/13 01:23 PM:

After 30+ years in the manufacturing industry I believe that poor documentation and commenting is one of the biggest contributor's to manufacturing and processing inefficiency.
Consulting-Specifying Engineer's Product of the Year (POY) contest is the premier award for new products in the HVAC, fire, electrical, and...
Consulting-Specifying Engineer magazine is dedicated to encouraging and recognizing the most talented young individuals...
The MEP Giants program lists the top mechanical, electrical, plumbing, and fire protection engineering firms in the United States.
Water use efficiency: Diminishing water quality, escalating costs; Lowering building energy use; Power for fire pumps
Building envelope and integration; Manufacturing industrial Q&A; NFPA 99; Testing fire systems
Labs and research facilities: Q&A with the experts; Water heating systems; Smart building integration; 40 Under 40 winners
Maintaining low data center PUE; Using eco mode in UPS systems; Commissioning electrical and power systems; Exploring dc power distribution alternatives
Protecting standby generators for mission critical facilities; Selecting energy-efficient transformers; Integrating power monitoring systems; Mitigating harmonics in electrical systems
Commissioning electrical systems in mission critical facilities; Anticipating the Smart Grid; Mitigating arc flash hazards in medium-voltage switchgear; Comparing generator sizing software
As brand protection manager for Eaton’s Electrical Sector, Tom Grace oversees counterfeit awareness...
Amara Rozgus is chief editor and content manager of Consulting-Specifier Engineer magazine.
IEEE power industry experts bring their combined experience in the electrical power industry...
Michael Heinsdorf, P.E., LEED AP, CDT is an Engineering Specification Writer at ARCOM MasterSpec.