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.



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.
2017 MEP Giants; Mergers and acquisitions report; ASHRAE 62.1; LEED v4 updates and tips; Understanding overcurrent protection
Integrating electrical and HVAC for energy efficiency; Mixed-use buildings; ASHRAE 90.4; Wireless fire alarms assessment and challenges
Integrated building networks, NFPA 99, recover waste heat, chilled water systems, Internet of Things, BAS controls
Transformers; Electrical system design; Selecting and sizing transformers; Grounded and ungrounded system design, Paralleling generator systems
Commissioning electrical systems; Designing emergency and standby generator systems; VFDs in high-performance buildings
Tying a microgrid to the smart grid; Paralleling generator systems; Previewing NEC 2017 changes
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.
Automation Engineer; Wood Group
System Integrator; Cross Integrated Systems Group
Fire & Life Safety Engineer; Technip USA Inc.
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
click me