The problem with programmers. How they affect society.

Years ago I wrote a technical paper titled, “Theory P: The Philosophy of Managing Programmers,” which was aimed at providing assistance to managers in reigning in their people. In a nutshell, I contend the best way to improve programmer productivity was to give them better specifications and create a uniform process (methodology) for them to conform to. I received mixed reviews on the piece; whereas managers loved it, a furor ensued among programmers. Nonetheless, I still stand by the conclusions of the paper.

It occurs to me though, programmers have a profound impact on society. Perhaps the most visible sign of this is our addiction to smart phones, where people are plugged in and tuned out. For example, we see people preoccupied with them on the road, which is quite dangerous, in stores, in the office, even in the gym where they are “tuned out” while they exercise. As an aside, I learned a long time ago not to try and strike up a conversation with anyone in the gym as they are all “plugged in.” This suggests our socialization skills are changing.

There are many other examples, such as remote control devices for TV, cable, DVD, radio, and Yes, old tape machines (e.g., VHS), all of which are as “user friendly” as a Ouija board. In my family room, I have four devices; one for the television, one for streaming channels, one for my DVD/VHS player, and one I’m really not too sure about. I hesitate to dispose of it as it might serve some purpose, kind of like an old metal key you do not want to throw away yet.

As an aside, you would think they would have invented a universal remote by now, but they haven’t. Actually, it shouldn’t be that difficult, a button for power, a button for volume, a button for tone (treble/bass), and a button for channel selection (Gee, it kind of sounds like the old TV’s and radios, doesn’t it?). This should be followed by a series of programmable function keys as on a keyboard (e.g., F1, F2, F3, etc.) which could include device selection, fast forward, reverse, pause, stop, etc.

This brings up a point, people use only a fraction of what these devices are capable of performing, primarily because we have specific needs and only use the devices as such. In addition, programmers tend to make such devices robust, with little consideration for “ease of use.” This is not new as we noted this phenomenon years ago with computers; we simply do not use them to their full potential.

You must remember, programmers are detailists who possess a myopic view of their particular problem. No, they do not see the big picture, just their small part of the overall puzzle. This is why it is important to provide the programmer with precise specifications, which has historically been the responsibility of Systems Analysts to provide. Unfortunately, such people are an endangered species and programmers are left to figure out both the problem and solution on their own. Not surprising, they will inevitably do what is easiest for them to do as opposed to how the end-user will implement it. This explains why devices appear complicated to the rest of us.

You should also understand programmers typically abhor standards as they consider it inhibiting their creativity. Let me give you an example, years ago IBM devised the Systems Application Architecture (SAA) standards which was intended for use on all of their computing platforms, including mainframes, minis, and PCs. This included standards for Graphical User Interfaces (GUI) for window design. The intent was to design windows in a uniform manner so that if a user mastered the use of one window, the user would know how to use all windows, thereby simplifying training and improving productivity simply by developing a common “look and feel” to all windows, regardless of the computing platform. Frankly, it was brilliant, but alas programmers resisted it and fought the standards until IBM backed away from them. Today, there is little continuity in how web pages work, much to the chagrin of the end-user.

We see other examples of technical snafus all around us:

* Web pages simply do not work correctly with no explanation (Help text is severely lacking). How many times have we seen a web page die on us, particularly when we are ordering something on-line? Quite often, the data we entered earlier has to be re-keyed into the page, only to die a second time, maybe because we didn’t upshift or downshift a letter in the proper sequence. Such editing rules should be accommodated by the programmer, but again, they ignore this and take the easy way out.

* In the event there is a power outage, or some other problem with television cable, we have to re-boot our cable box. This takes us down a cryptic path whereby we do not know what we are doing, and have no clue whether the repair process is occurring properly. I still find it rather amusing when customer service reps admonish us to unplug the device, wait 30 seconds, and plug it back in (whereby it takes us on a countdown to nowhere).

* Voice Mail jail is still the norm for just about all companies. I cringe when I hear, “Press-1 for this, Press-2 for that, etc.” Even after you entered your name, rank and serial number two or three times, the customer service agent will inevitably ask you to repeat it all over again, assuming someone returns your call. They throw up these electronic walls intentionally as they do not care about Customer Service.

Instead of simplifying the user experience, programmers make it more complicated, again, because it is what is easier for them to program, not what is convenient to the end-user. Such a mindset forces us to expect less, not more, from sales and customer service.

Here is the point: Instead of adapting technology to human behavior, humans have to adapt to the technology. We are the ones truly being programmed, not the machine. This is like putting the cart before the horse, all because we bow to the creativity of the programmer, not because it is right.

All of this influences social behavior. For example, we are less likely to engage in conversation, we lose respect for the human spirit, we lose patience, and we become more irritable and prone to heated arguments and fights. All because we resist properly managing programmers and allowing them to do whatever they please.

One last note, I recently had to swap out the SIM card for my mom’s aging flip-top phone, a process I estimated would take maybe five minutes, at most, to perform. First, I discovered I couldn’t lift off the back cover as easily as the instructions indicated. I basically needed a hammer and chisel to break in, but I also considered a little nitro. I then pulled out the battery to access and replace the SIM card in the back. After reinstalling everything, I turned on the phone, only to discover it claimed the SIM card wasn’t installed. I again brought out the hammer and chisel, pulled everything apart, and found I had indeed installed the SIM card properly. In desperation, I called the company’s customer service who explained to me the phone had to be activated. Note: There was no mention of activation in the documentation I received. Nonetheless, the phone finally became operational. So, a five minute operation ended up taking just over an hour to complete. Is it any wonder why I despise programmers?

“As the use of technology increases, social skills decrease.”
– Bryce’s Law

Keep the Faith!

P.S. – Also do not forget my new books, “How to Run a Nonprofit” and “Tim’s Senior Moments”, both available in Printed and eBook form.

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 40 years of experience in the management consulting field. He can be reached at timb1557@gmail.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2019 by Tim Bryce. All rights reserved.

Listen to Tim on WZIG-FM (104.1) in Palm Harbor,FL; Or tune-in to Tim’s channel on YouTube. Click for TIM’S LIBRARY OF AUDIO CLIPS.Advertisements