That "other" thread got me thinking...the one with the alphabet soup I didn't understand.
Am I the only programmer (code monkey) on OT?
I was thinking today that most of my job is not writing code or even testing--it's going to endless meetings and explaining that yes, I can make a program do just about anything, but I can't always do it on time and under budget. People have no appreciation that decisions made years ago often make certain changes very easy while making others very, very difficult.
Think of it this way: someone asks me to design a car. They want it to be fast, carry 10 people, and get good fuel economy. I am told that it is for commuters so luggage and off-road capability are not concerns. I design and build the car. It works exactly as intended. A month before it is to be mass-produced, I am asked to make it perform off-road, haul luggage, ford rivers, and it can't cost more to produce or get worse fuel economy.
These concepts are very easy to understand when the product is physical, but when the product is more abstract, it seems very few people have the capacity to understand how changing the purpose of a design can add to cost and hamper performance.
I designed a very cool piece of technology a few years ago. Think of it like making a car out of life-sized legos. Changes are easy to accomplish by picking the right components from the inventory and snapping them together. Because some changes are very easy and quick to accomplish, some people wrongly assume that
all changes are easy and quick to accomplish. Sometimes I have to design a new "brick" to meet a new need and people get upset when it takes longer and costs more than a change that was merely a different combination of existing components.
Oh, and one thing I've learned to do is speak in analogies to physical things people can understand.
