Saturday, August 29, 2009

He Who Knows...


Nothing much to do with rules specifically but more with things in general. I ran across an old by-line that I used to use a long time ago:

"He who knows not and knows not that he knows not is a fool.
Shun him.
He who knows not and knows that he knows not is a child.
Teach him.
He who knows and knows not that he knows is asleep.
Wake him.
He who knows and knows that he knows is a genius.
Follow him."

This was supposedly an old Hindu proverb but who knows? Maybe Ben Franklin made it up but it sounds too psychological to be Ben. On large projects I've met all kinds distributed in a natural distribution pattern. Maybe one or two at the top and one or two at the top. Maybe. But lots in between which is pretty much a compliment to programmers everywhere.

Here's the problem: What to do with the first one? Management picked this guy and he/she is a "valuable" member of the development team. I had to point this out to a company once after a two-week gig to help them get started with rules. I told ONLY the Senior Director for the project after he pointedly asked about each person. But his pride-and-joy manger had picked that individual to move from being a contractor to leading the rule development team. The guy had been doing C/C++ stuff for two years and had made very little progress toward a real rulebased system. But, in his defense, his GUI stuff looked really cool.

Truly, he didn't know rulebase development and he didn't know that he didn't know. Their regular employee on the team (who would have to work for this ninny) was more of the second kind; eager to learn anything that you could teach him. I'm not sure where the manager fit on the chart but she certainly was convinced that she had made her decision and she was going to back it up 100%. Also, unfortunately for me, she was the one who hired me and I had to tell her the same thing. They were ecstatic about the analysis that I had done until 2:00 the afternoon that I was leaving. By 2:15 all bets were off. So, I didn't get called back for the traditional "sanity check" because the bare, naked truth was out of the bag and on the table. Now they had to justify keeping these plans and that meant that they did NOT want anything to do with facts.

As one of my old managers used to tell me, "James, you have great technical skills. It's your 'soft skills" that need work. You don't know how to tell anyone diplomatically that what they are doing is trash and that their development personnel need five years training just to get up to the zero level. Sometimes you can't tell someone the truth straight out - you have to sugar coat it so that it tastes better." He was right, of course. Maybe one day I'll find a home where I can just DO things and not have to worry about feelings. So, that's my tale of adventures with the upper class of management. I don't belong there. Hopefully you can learn from that and be nice to nit-wits and dweebs. After all, if God didn't love them he wouldn't have made so many of them. :-)


1 comment:

woolfel said...

I've been in the same situation in the past. I'm of the opinion it's better to tell the customer the cold hard truth, even if it means loosing the contract.

It's definitely gotten me in hot waters in the past, but at the end of the day, I'm not willing to lie to a customer just so I can make a few extra bucks. Being honest isn't a road to monetary riches, but it is a road to spiritual riches and peace of mind.

Plus, jobs come and go. At the end of the day, you have to be able to look yourself in the mirror and know you did the right thing.