A Meeting With Half Knowledge

‘Half knowledge is dangerous’.
One of these days, I met this person who is a shining example of such half knowledge.

Unfortunately, he happened to be a client, whom I met, to elicit software requirements from for a system we have undertaken to develop for them.

I think it is the worst kind of a situation in which to be with someone having ‘half knowledge’.
Because you are helpless.
Normally, when you meet someone like that, you would ignore him. Or you would laugh at him. Or you would show him your contempt. You would give attitude.
Or you would show him a mirror.
But if it happens to be a client, you can react in neither of the above ways. You continue being polite, continue to smile, nod your head, exercising the kind of self control you thought you were incapable of and hold yourself from flinging that paperweight at the idiot facing you.

‘I perfectly understand what you are saying’, ‘I know…’ - that’s how he would begin every sentence.
Here was someone who knew a little something about systems and technology and thought he knew everything.

The meeting started.
We were the technical people, there to advise him, to help him understand various options. And he would not let us do our job. He insisted on doing most of the talking. He talked as if he knew all about how software systems worked and tried to dictate details of how to implement the system.
It is like going to a doctor and telling him what malady you have, which part of the body and how to operate.

He would say something ridiculous and when I corrected him, he would say, ‘I understand what you are saying, but…’ he would not admit that there was a possibility he did not know something that we did.

He would present one complexity of the system that he perceived claiming it was a challenge and suggested an alternative. When I proved to him it was really simple, he would immediately present another challenge. When I showed him, it could be easily done, he would go on to mention a third.

He assumed too many system constraints. The system cannot handle this, so this feature will have to be done this way… and so on.

One particular module required creating user accounts for general public - like shopping sites, like Amazon, where any user can create an account and have access to very minimal features - mostly his own profile, while the bulk of operations and functions remained accessible to the system owners only.
At this his became wide eyes and he started shaking his from side to side saying ‘Oh! This is dangerous. These public users, after logging into the system will surely hack it and steal his financial reports. No no… I cannot allow this to happen’
Even the US president would not have reacted like that at the prospect of allowing someone access to his cabin where a hundred missile launching controls had been fixed.

‘I have seen a hundred websites being hacked like that’!. Yeah right. I have seen a hundred people dying in road accidents, so now on, I will not step out of my house!

I could not help smiling at my team mate who smiled back. And he saw us smiling. I wish we had continued to humour him. From then on a stern look took the place of those unstoppable ‘I know technology - no less than you guys…are you impressed?’-smiles of confidence on his face. It was funny.

But this guy was relentless!
While all clients insist on having legacy data migration as the very first step, this one wanted no offline data to be loaded into the system, for various reasons that did not make sense. After much questioning I figured out what his problem was – he though there was no space in database or tables for these offline things and some extra work would be required to make room for them!
It again took me 30 minutes to make him see that it was just a matter of inserting a few rows of data into the already existing tables.

The last straw on my back fell when he tweaked his real world business process itself to accommodate a system constraint that he perceived.

I leant forward across the table and told him it did not make sense. ‘You should never alter business processes and rules to accommodate system constraints. We work around system constraints and overcome them to put the business rules in place. The system exists for the sake of the business and not the other way round.’
I showed him how the constraints he was assuming could be overcome and then he realized I was right. But of course, he would not admit it.
When caught on the wrong foot, he denied having said something that he had said only 10 minutes earlier. He shrugged and asked ‘Did I say that? No I didn’t” !

Lastly, after saying many things to prove his ‘expertise’ in payment gateways to us, which actually revealed how dumb he was, he asked us to show him some work we had done in integrating payment gateways with applications.
When I showed him the interfaces, he said, “O yeah.. I have seen all this… but”. and I knew he hadn’t seen any.

The very first thing I said to my teammate as we came out of the meeting room was ‘Half knowledge is dangerous”.
“Very”, came the reply.

“I would rather keep my mouth shut and let people wonder if I am dumb instead of opening my mouth and remove all doubt” nice quote...

I understand that a client is a client (I refuse to use the phrase ‘client is God‘ even accidentally. Ouch!), and we have to humour him but we should not lose sight of our higher purpose/goal of delivering a quality system that will address all of the client’s IT needs. Sometimes we have to assume a paternalistic attitude towards the client even though he may prefer to be treated like an equal. In the long run it is rewarding.
This is one of those examples of the meaningless, short sighted practices in the IT industry - getting stuck in protocols, processes, schedules, niceties and losing sight of the higher, larger goal.