Everybody reacts to certain sounds in ways that range from cringing to anaphylactic shock. It may be chalk squeaking on a blackboard, fingernails scraping a screen, or even two pieces of corduroy rubbing together.
For me it’s the fingernail/screen combination. If I’m ever captured by an enemy bent on learning all of my secrets (both of ’em!), all they’ll have to do is brandish the screen in front of me. I’ll cave in an instant.
Sometimes whole sentences can cause just as intense a reaction. Many InfoWorld readers react to various examples of ManagementSpeak like those that begin this column. (Me too.)
Another source of acoustic chafing: People who tell you what you’re thinking and feeling (“Don’t get defensive,” is the perfect example, requiring extraordinary self-restraint and conversational dexterity in response). Deal with what I say and do, pal. I’m in a better position to describe my thoughts and feelings than you are.
There’s a new kid on the block that puts the others to shame. It goes like this: “The technology is the easy part.”
I hear people say this all the time these days. These people have never written a line of code in their lives, of course, and that may explain why they’re so comfortable saying it while calling programmers “bit-heads” and “nerds.” For them, technology is the easy part. They get to toss out high-level, fuzzily stated requirements. Then they sneer at programmers who bug them with questions, using the popular put-down: “Clearly you’re not comfortable dealing with ambiguity.”
There’s not much point explaining that it’s C++, not you, that’s uncomfortable dealing with ambiguity. These characters are so busy being self-important that they don’t have the time to deal with a mere technologist, who after all gets to deal with the easy part of the problem.
With a little less arrogance and a bit more patience, these important businesspeople would learn that they do indeed have a very difficult job, which they often shirk. That’s the process of clearly and unambiguously defining what the business needs. Usually, this means creating a detailed picture of a business process that doesn’t exist, along with every resource that process will need to be put into practice.
That’s hard. It requires, time, thought, and patience, so it usually goes undone.
Yes, when business planners do their jobs well they make the job of the technologist easier. Not easy, but easier. Somebody has to take the big picture and refine it into the kind of detail a data designer can translate into a schema and a programmer can translate into code. Too often, the people who end up having to do the refinement are the programmers and data designers, who collar the business planner in the hallway to ask annoying questions.
I’ve known IS programmer/analysts who have been assigned to a new business unit to “create the technology” and instead have designed every key business process along with defining the technology, up to and including the invoice design.
(Which, by the way, points to a solution. Place a programmer in a business area, actually doing the work. That puts the programmer in a great position to envision, and immediately build, efficient, technology-centered work processes. Try making this an endorsed system-design methodology.)
The devil is in the details, of course, and the ultimate level of detail is the actual code. It takes talented programmers to write good code that gets the job done. I guess it’s because the devil is in the details that so many businesspeople simultaneously denigrate and demonize the technologists who translate their “important concepts” to reality.