I was somewhat frustrated by this because I wrote software professionally for many years.
The gist of it is that the programmers are never put out "in the field" to experience what is actually needed.
Hands-on would get their minds right pretty quick.
It's a sad commentary because most of the programmers are actually pretty bright people - quick on the uptake.
Just like very few customer service supervisors have ever phoned in to their firm and experienced what a customer goes through trying to reach a live human being.
Just like very few customer service supervisors have ever phoned in to their firm and experienced what a customer goes through trying to reach a live human being.
Just like very few customer service supervisors have ever phoned in to their firm and experienced what a customer goes through trying to reach a live human being.
When I worked for a Rent-A-Rig oil company as a programmer, I had a "See Jim and figger out what he wants." request.
As soon as I walked into Jim's office, he says "What the hell are you people going to do to me now?" Told him I was to write a program for what he needed, and that this was his chance to get his thoughts in code.
As I left, he said that I was the first programmer to actually come and ask what was needed and not just given a program "some guy downstairs wrote."
Where possible, I always went to the user and sat down and talked things through. During the session, I'd tell them about other data that was available, and could they use it. Half the time they'd light up with "Hell yes! I never thought of that!" and implemented some pretty neat stuff.
One I remember what a mechanic's To-Do list. When the guy opened up a repair request, we showed him all the other stuff that needed repair in that same area so that he didn't have to close up the cover, only to reopen it again for the next job. Sometimes saved a ton of time.