HOLDING A JOB HOSTAGE
Posted by Tim Bryce on September 16, 2015
BRYCE ON MANAGEMENT
– How programmers do it, but why does management accept it?
(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.
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!
Note: All trademarks both marked and unmarked belong to their respective companies.
Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com
For Tim’s columns, see: timbryce.com
Like the article? TELL A FRIEND.
Copyright © 2015 by Tim Bryce. All rights reserved.
NEXT UP: WHY OLDSTERS ARE MEAN – And, No, we’re not like this all the time.
LAST TIME: THE THREE TENETS OF MANAGEMENT – Is there any real management going on anymore?
Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; and KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim’s channel on YouTube.
THE BRYCE IS RIGHT! 
Raymond Sean Walters said
[the real culprit is the manager for allowing this to happen]
I have always observed it is tough to be a manager when one is afraid to “manage”…
LikeLiked by 1 person
Tim Bryce said
A B.H. of Boulder, Colorado wrote…
“Just a quick FYI. I’m not sure it holds for the commercial/civilian world, but in the government/military environs, the concern is more over the LACK OF DOCUMENTATION – because they run out of money on the contract, and the first thing to be considered “dispensable” is documentation and the next is training. It’s the old “parts is parts” syndrome when it comes to engineers and programmers. Management in those environments actually believes that if an engineer/programmer leaves, they’ll simply go hire another one and everything will be fine.
I once had dealings with a military group out in San Diego. In fact, I always hated seeing their rep show up in the NSA parking lot, because I KNEW he was coming to see me with a “I’ve solved your problem” statement, even though I didn’t know I had that problem until he told me about it. Anyway, he once provided me with a program listing (this is back in the days when we were using BASIC interpreters for programs – it’s been a VERY LONG TIME now). The program was written using Tektronix BASIC and it had a little over 50,000 SLoC to slug thru. There was ONE – count ’em – ONE comment line at the very top, telling you the name of the program and the name of the programmer. The good news is that it was completely unclassified – it was an HF Propagation Prediction program that attempted to provide what we would call a “now-cast” prediction instead of one that was based on probablistic calculations that tried to predict a month in advance. Over time, I was able to dissect the math involved, and even found some inherent and fundamental mistakes in the calculations. But, that wasn’t MY JOB! I was just doing that out of curiosity to see how they got the numbers they presented to the user.
I saw this phenomenon (running out of money on the contract before documentation and training were in place) more than once, so it was NOT just an isolated instance. So, while programmers inherently do not like documenting their work, sometimes there are other factors at work.
FYI, my late wife, who always programmed in source code and native (hexadecimal and octal) code in real time used to take great pride in documenting (some might say “over-documenting”) her code, believing that she might not always be around to fix a problem and needed to give the programmer assigned to work on her modules the best chance at understanding what she was doing and why. In fact, her code often included much more in the way of comments than the actual code itself. Her feeling was that the comments don’t get compiled, so it changes nothing in the final object code that is produced if you have a lot of comments.”
Tim’s reply: “That is just my point. Under our “PRIDE” methodology, everything is documented before you write one line of code. In other words, there should be no guessing in programming and we see it as a simple translation function. But if you have no specs or an idea of the logic behind the program, you will spend more time in programming.”
LikeLike
WHY OLDSTERS ARE MEAN « THE BRYCE IS RIGHT! said
[…] HOLDING A JOB HOSTAGE […]
LikeLike