Thursday, December 06, 2007

The Difference

Between leaders and followers. Between proactive and passive. Between great and good.
We have been stuck with a few issues in a solution that we are implementing at client site for the past 10 days. The solution was developed to cater to a specific business need about 7 years ago by my company in association with the Development guys. And as part of the solution, several standard packages that are a part of specific business modules are called to fulfil specific functions.
Two of the issues we are facing are clearly stated limitations of the solution that the client wants to be handled. The other two are problems with the standard packages that are being called. I have broken my head over those two for the whole of last week and dug into the ultra-extensive code to isolate the exact SELECT statements where the problem is, as pointed out by log files that we have obtained (anyone who has some experience in the software industry will know what it is to look into someone else’s code and then make sense out of it, not to mention that this particular code refers about 1 billion packages!!).
Now we supplied these SELECT statements along with the log files and a detailed problem statement to the Development team so that they could help us figure out what the problem was and look into it if it was a bug in the standard code.
And this is the response we got: Since your company developed the custom code, you should look into it. Kindly tell your own guys to investigate. We cannot provide development bandwidth for this. We can only provide pointers.
Now the response on the limitations and the workarounds provided by the guy who worked on the solution 7 years ago and is much higher up in the hierarchy– he actually looked into the whole problem and took the effort of drafting two vary detailed mails with the reason (as he remembered) why the solution had a particular limitation and what we could do as a workaround. He gave examples with data fished out from some documents he had from the past and explained the whole thing in a nice informal manner. And given this guy’s designation, I can imagine how difficult it is for him to take out the time to revisit something you did ages ago and explain it to someone else.
I am forced to wonder if it is attitude and not a limitation in IQ that is coming in the way of the Development guy seeing that the problem is in the standard code (the exact name of which has been provided to him). Just because the custom code calls a standard package does not mean that it is our responsibility to debug even standard code which was never altered…only used. It is like saying that since the Audi was customized to have a right hand drive in India, Audi has no responsibility of any problems that the engine presents in India; we used the standard code, it was driving the whole solution. But since we wrote the code that calls the standard code, Development is free to wash its hands off the whole thing.
And that is the difference that I am talking about. Owning up to things, no matter what the consequences. We are always on the lookout for ways to shrug responsibility off especially in the face of adversity (considering that our client has actually escalated the fact the Development is not giving the right attention to the bugs that we have raised)…But it takes the heart of a leader to stand up for something.
And it is this difference in attitude, in vision that has gotten the Senior guy where he is today and also the reason why the Development guy remains where he is. He may be good. But he is not great enough. I am appalled at the apathetic behaviour he displayed but I also have learnt a business lesson that will last me in good stead - Own up. Stand up. The more fire you face, the brighter you shine…like Gold.

7 Thinkers Pondered:

sanchapanzo said...

sometimes people tend to forget who's the priority .. guess, the person who's close to client feels the tremor.. and rest are even not feeling the aftershocks..
sorry state really..
the farther people are away from reality such problems are bound to recur.. sad commentary though :(

Vinni said...

i was wondering where u leading us to all the while till i read the last two paras. :-) yes, now u know why i am heading for hardware and not software!

Utsarg said...

Great lesson to learn early in the career!

But I feel there is one more important lesson to learn here. The senior PM took pains to clarify the issue and suggest a workaround because it was his creation, he might still enjoy taking credit and priding himself for the piece of code referred by a billion packages.

On the other hand, dev guy shied off from the responsibility because he must not have seen any motivation to get involved. He would feel putting his time in developing something of his own more worthwhile than little enhancement in somebody else's creation.

Everyone cares for his/her own baby and no one likes to clean somebody else's shit!

I hope I am not missing something completely. Correct me if I am wrong.

xunz said...

This is corporate world... u'll come across some interesting characters ;)

u have created programming environment in ur writing...that's cool!

Anupama Kondayya said...

Hey Sanchapanzo,

You are right...the person who wears the shoe knows where it pinches...I think more than being away from reality, it is closing one's eyes to reality that causes recurrences of such problems.


I don't think this is a problem that can be attributed to the software industry although it has manifested itself through that...this problem could have occured anywhere - somebody washing his hands off his responsibility. Thanks for the comment.


What you say might be correct to a certain extent. But when someone is the head of a team handling a whole module it is his responsibility to make sure there are no bugs in it, whether or not he wrote the code (I am sure his job profile would have been made clear to him before the promotion). And if you are saying that nobody would want to care for anyne else's baby, then the whole industry would collapse, hardly any creators of software code (simple or complicated) are available as long as 7 years later to comment on it...I am sure you know for how long each one sticks to his job/company. So in that case, the whole idea of software support goes for a toss. I hope I have elucidated my thoughts well. Do let me know what you think. And thanks a whole lot for stopping by :)

Utsarg said...

I still say that nobody cares for others baby, unless he/she is getting paid for it. If you think cleaning or maintaining others' code is a favour you are doing, it will become social service (for the programmer society) and it no longer remains a business or industry.

My assumption here was that the support for the code was asked as a favour and no one was bound by duty to provide it. If, as per contract, dev guy had to support it, then its clear that he is work-shirker and hopeless case of negligence to me. Comparison would be meaningful only when both were bound by same conditions. More than leadership, its question of how dutiful these guys are.

But yes, being dutiful and enthusing sense of duty among his/her followers is an important quality of leader. Leader is a guy who owns the task, takes responsibility for all its outcome and has the vision to see in future and realize implication of each of his/her actions. He does this under no obligation, but out of passion to do it.

Doing what you are supposed to do is something what is expected out of you. Leaders differentiate themselves by going beyond whats supposed to, and create examples for us to derive inspiration.

And isn't that what you also are saying :-)

Anupama Kondayya said...

Hi Utsarg,

We raised a priority 1 bug for the issue and it was by no means a favour we asked for. Yet, it did not get the attention it deserved.

Nevertheless, I do completely agree with the views you have about leaders. I think going the extra mile, taking responsibility, being accountable are all leadership qualities that are hard to find. We could do with some more leaders in our vision-starved society.