Applied Programming: Reuse

Information Technology / Programmer wannabes invariably have the word 'Reuse' drummed into them almost from the first day as a student. This is one probable reason we Indians are usually good programmers. We reuse everything, even our Soul ( see: reincarnation )

Jokes apart, the reuse that is drummed into an IT student is usually in the context of OOP, or programming where we talk of reusing the code written once to be used elsewhere. The term reuse, though, goes much further. We reuse a great many things without even realizing it. For instance, software development contracts will often have similar, even almost identical clauses. The reason is that similar problems are expected to arise, and therefore are dealt with in a similar manner. Whilst these rudimentary applications of reuse are valuable, reuse itself can be far more valuable by way of mentoring (something that only came to mind after I read this)

The reason I choose to link mentoring to the concept of reuse is because mentoring provides an apprentice with the opportunity to capitalize upon the experience of the mentor. Organizations such as IBM, Microsoft, InfoSys have mentor programmes to help their employees growth.

What should I look for in a mentor?
The thoughts that come to my mind are -

1. Trust & Communication (the two must go together)
   
2. Better than average understanding of the domain (Finance, Software...) under which the mentoring occurs
   
3. Better than average Time Management skills, and as a corollary - not a workaholic
   
4. Compatibility

I put in the third point - Time Management - with some diffidence because -

• It simply doesn't make sense to assign someone as a mentor, only to find they're not able to justice to either their primary role or their mentor role.
  
• The apprentice might pick up the bad-skills too
  
• Poor time-management might also mean a stressed work-style; in the long run this could be detrimental to health, and to teamwork.

In winding up, reusing knowledge gained by others is something we do all the time - right from the first 'A' at school, this continues throughout life. The broader form of reuse of experience by Mentoring provides a means to build a relationship between the mentor and an apprentice that could potentially be capitalized upon by the organization.

Organismics - The Balancing Act

I've been working in/around IT for several years now. As in any industry there are companies that merely survive, and there are those that thrive. One part of it is the timing involved. Timing is not everything though. As it caters to more customers, as it creates different products across different geographical locations... as it grows, each company has it's own share of teething troubles.

Those companies who make it good & succeed do so because they approach the task at hand as a single living breathing entity. Management are the brain, deciding upon what to do. Human Resources are the auto-immune system, working to ensure the cells in the organization are content, and healthy. The various departments are the different organs performing their tasks to keep the organization function optimal. The Department head is the synapse, reporting on the status of the department to the brain.

In all my time (that sounds so ponderous ...) i have never seen a person to be irreplaceable; In an organization, none of us are. Each individual may be likened to a member of a football team. Whilst each of us is capable of playing the position of the goalkeeper, the forward, the defender; we may do better at one particular position.

Compare playing football to working in an organization -

• Project is the goal
• Task assigned to the team member is the ball
• Coach, manager/supervisor, defines what is expected of each team member
• Each team member knows what to do with the ball, but how to do it is his prerogative

The entire purpose behind an organization is to commit all necessary resources into play at the same time towards achieving a common goal. The key, as we all know, is to communicate well within ourselves. Where communication fails or isn't complete, it results in friction causing avoidable loss of time, and effort. A failure to communicate effectively manifests ultimately as conflict within the organization.

No organization is ideal. There is always some conflict involved. To even attempt resolution of every tiny conflict would be an overkill. As in life, it is neccessary to choose our battles. But every single battle must be fought to a plan. The first thing to do is to identify the enemy. The disgruntled employee who talks down the new employee is not the enemy; why he is disgruntled, and why he chooses to vent at a newbie is what needs to be identified. If anything, the fact that a person is dissatisfied is cause for concern; the tip of the iceberg, so to speak.

As with any problem, a solution can only be found after the problem is well-identified. Before we even make an attempt to resolve the conflict, we must identify the conflict. Broadly, in my experience, symptoms of conflict are these -

1. The most obvious is probably finger-pointing within the team; it's the equivalent of the goalkeeper claiming the player who passed the ball back to him is the reason for the own-goal. Each task assignment is met with the equivalent of - 'Why Me'?
2. The second most obvious symptom is lack of pride in the work being done; this typically manifests itself as that murmur which goes like 'what's the use? even if we achieve it, this will never see the light of the day & it will never benefit us. we'll always remain anonymous in the background'.
3. The third, and probably the least obvious symptom, is when nothing obvious is mentioned. Things aren't obviously wrong; they're quietly wrong. This is probably the most dangerous form of conflict within the organization; conflict of this type only becomes apparent when things are almost at a head, nearly irreparable. Say, for instance, the rest of the team relies upon one piece of work assigned to Vishwas; e.g. a daily database update. If now Vishwas does his task, but _regularly_ fails to convey the relevant details to the rest of the team then something is quietly wrong... and it affects the entire team. As i've mentioned earlier, the entire purpose of being there as a team is to work together to a common goal. Here, Vishwas may have personal troubles which affect work, and instead of choosing to confide in his team-mates atleast as far as the work-related aspect is concerned, he's going it alone; That is cause for concern.

As part of the effort to avoid conflict, the person responsible for the team might

• Impress upon the team, the need for each member of the team behave responsibly towards the output expected of the team.
• Define & Enforce the guidelines for unequivocal communication.
• As a corollary to the above, continually make sure team members refrain from 'guessing' what is expected.
• Prevent exhchange of disparaging remarks between members. If possible by calling on their sensibility & sensitivity. If necessary by drawing their fire to him.
  

Each occurence of the symptoms listed above are not a sure-shot indication of conflict. They are merely signs to watch out for. It is upto the more experienced persons on the team to notice these flags in the context of the work at hand, and the general mood of the team. There is no panacea to deal with conflict. Each of us is an individual, and our troubles are personal too. Therefore, to achieve the best results, conflict too is best handled one-on-one, and subject to the need of the hour. As with any malaise, prevention is better than cure.