The trouble with software people

It started back in 1985. That was when I noticed the trouble with software or, more specifically, the trouble with software engineers. The trouble was that companies were promoting software people with poor programming skills into management. Everyone in Silicon Valley knew that many software engineers getting promotions were the high-dollar folks who could not write good code. The companies they worked for could not easily fire them, so they did what companies often do: They promoted those who lacked programming skills to management. After all, it is a rare breed who can write good, tight code, but anyone can fill out time cards and go to meetings. Unfortunately, those who got promotions were doing more than filling out forms and going to meetings; they were also making product decisions.

In 1985, I was designing an ultraviolet-erasing system for a wafer-probing machine. My boss was a former software engineer. We didn’t want the high-voltage-ultraviolet lamp to go on while operators were servicing the machine. We added a key switch to the front panel so a service person could lock out the high voltage. This step required my adding an AND gate to the control circuit.

It was basic: For the lamp to go on, the service person would have to unlock the key switch and the control signal coming from the machine’s operating system. But, as I said, my boss had been a software engineer. He didn’t like the two-input AND gate that I used for the key-switch function. What if they wanted to change something in the future? So he told me to put in a PAL (programmable-array logic) with eight inputs. In that way, they could have “programmability,” he said.

The effect of these former software engineers’ product decisions is evident everywhere. Rather than have any courage, they make everything configurable, as that former boss of mine tried to do with a PAL. Worse yet, the few times that any sane, normal person might want some configurability, these software bosses fix things in some arcane, absurd procedure that may make sense to unsociable, awkward loners but surely don’t make sense to the rest of us. What do you expect from people who count starting at zero?

When you think about it, almost every major development in the last decade has been the result of overcoming the problems that software managers cause. Remember when the software bosses had us dialing up bulletin boards and using the Kermit protocol and an unbelievably complex method for looking at a couple of files on another computer? The Internet was a victory and an obliteration of the geeky, painful, arcane software-boss mentality.

Steve Jobs might have a reputation for being difficult, but he knows software absurdity and has the guts to demand better. A friend told me about Jobs’ evaluation of an early version of a backlight for the iPhone. As the backlight dimmed, a perceptible flickering occurred. Software bosses tried to mollify Jobs with the usual software razzmatazz about DACs and square-log gamma curves. Infuriated, he just walked out of the room. The iPhone instead ended up with a control signal with ultrafine steps and smooth dimming. Way to go, Steve. Don’t take any guff from those software bosses.

Contact me at paul.rako@edn.com.