How programmers do it, but why does management accept it?
Click for AUDIO version.
For as long as I can remember, people in the Information Technology business have enjoyed relative immunity from being fired from their job. This is primarily because when they write source code (text which is compiled into electronic format) it is difficult to read and understand the logic behind it. In most cases, if a programmer has written a program featuring a special calculation or feature, employers are afraid to release the person as they fear the logic will walk out the door with the person, making maintenance or modification of the source code almost impossible. This can be easily overcome by developing documentation, both within the program using comments, and externally where the purpose, description, and logic of the program is explained, as well as its interfaces to other programs and file structures. Unfortunately this rarely occurs as programmers stubbornly resist writing documentation in fear someone might read it and criticize their work. By doing so, they have safeguarded their job and now hold it hostage.
Think of it this way, it is like an architect being the only person who knows how a building is designed. Who would fire him? After all, there are no blueprints and the design is filed away in the person’s head.
Frankly, I do not understand why managers accept this behavior, but they do. Consequently, it becomes difficult to reprimand an employee. Further, it becomes rather expensive to dissect a program and modify it without disrupting the interfaces to everything else linked to it.
Another problem is when programmers leave a company they often take code not belonging to them. Regardless if it was written by the programmer or another, most programmers feel entitled to the code so they may use it with their next employer. This is incredibly illegal and could do serious harm to the company, as it is their intellectual property, but it is a common occurrence in business today.
What I have described herein is common knowledge inside the Information Technology field. The outside world is generally unaware of this problem. There are other technical positions doing this as well, but it is in programming where it becomes a flagrant problem. Outside consultants also like to play this game and deliver software, but no documentation, thereby creating a dependency on their services. Again, the best way to overcome this problem is to insist on verifiable documentation, but managers either do not understand the problem or naively believe programming is an art form which can only be performed by people who cannot be inhibited by structure or discipline. This is just plain nuts. Under this scenario, the real culprit is the manager for allowing this to happen, not the programmer.
I have always believed the best way to make yourself indispensable to a company is by demonstrating a positive attitude and a professional work ethic (e.g., craftsmanship), not to mention delivering on time and within budget. Alas, this appears to be an attitude from a bygone era.
Keep the Faith!
