The response to last week's column about introverts had me thinking about some of the experiences I've had with technical professionals. Last year, I wrote an article titled "Dumb and Dumber" that discussed security problems that resulted from "stupid users." My book, Spies Among Us, also presents case studies of some of my penetration tests, where the behavior of users resulted in billions of dollars of potential loss.
As I wrote that column, I remembered the old cartoon of one programmer telling other programmers, "You all start programming, I'll go find out what the users want." Sadly, there's a lot of truth to that cartoon. I've had many of experiences where the obliviousness of computer programmers rivals that of the users.
It can run faster -- but it can't get out the door
In one case, a fellow programmer came to me to complain about how some people he promised to write a program for were suddenly all over him for the program. I asked him how long they'd been waiting. He replied that it was over a month but asked, "Why are they all of sudden complaining now?" A week or so later, I asked him if he ever got the program delivered. He replied that he had finished it, but was rewriting it in assembly language because he thought it would run faster.
Geek-to-user translation service
In another case, I was on a project team that was improving a system in use by an Army field unit. After we got the first phase of the update implemented, a user came over to me and the lead programmer and said something to the effect of, "This system sucks. It's too slow and it doesn't give me what I asked for when I want it."
The bewildered (and upset) programmer replied, "I can't fix 'sucks'. I need to know specifically what 'sucks' means."
The user was standing there, equally bewildered. I told the programmer, "The system performance level is unacceptable."
The programmer replied, "Well, the reason the system may run slow is that the semaphores inherent in the Unix operating system, as well as the overhead typically associated with a relational database management system, use a great deal of the processor availability."
The user turned back to me. I explained, "There's nothing we can do about it. It's as fast as we can make it."
The user said, "OK" and walked away "knowing" that we understood his concerns.
Created in his own image
I worked on a project team installing a system in the Pentagon. The project manager left, and the our boss picked the most senior programmer to take over as project manager. He decided that he wanted to review every subroutine.
Without getting too geeky here, everyone else on the programming team had a uniform way of indenting "if-then" statements. The new manager preferred a different way and said that he couldn't read the code the way everyone else wrote it. He then started going through every program file to reindent the code his way.
He also started to microanalyze the program logic. For example, there are sometimes multiple ways to create a logic test, such as "If x=True" or "If x is not False." The project manager went through every program with the programmers to find out why they wrote the logic the way it was. He then argued with the people to find out why they didn't do it the way he would have done it.
This was only the beginning. Needless to say, the project, which was ahead of schedule when the manager took the reins, fell weeks behind. Also needless to say, nobody came to his defense when the client lodged major complaints about the delay.