Personality conflicts are unavoidable and if it is among managers, it will send wrong signals down the line and will directly affect the productivity of every individual, says Dr R Srinivasan

"Email should not be used for confrontations, criticisms, sensitive information, politically incorrect topics, and legally actionable claims "

The most important requirement in a software development center is good coherence, good understanding and good communication among the team members. History tells us that knowledge dissemination is mostly through direct interaction and exchange of ideas. However, in some cases, personality conflicts are unavoidable and happen due to some reason or the other and if it is among managers, it will send wrong signals down the line and will directly affect the productivity of every individual. Ultimately the organisation is the one that will suffer from customer's wrath. As William Brown says, "When the conflict erupts into ballistic verbal exchanges, verbal assassinations are carried out against each staff to senior management." The resulting antipattern is called as 'The Feud'. Feud at management level can carry on for a long time unless good understanding is restored. R Oakes, in his presentation in the Health Care Software Development Conference at Boston in 1995, says "there is no problem that a pizza party cannot solve," where a direct communication happens and the difference of opinion is sorted out, it paves the way for a new and amicable atmosphere in the organisation. So the refactored solution for this antipattern is "sit face to face and work it out."

Another area that a software organisation has to take care of, is the way in which the e-mail facility is being used. Under the parlance of Internet-based transactions, either with the customer or with the co-worker in another place, e-mail should not be used as a medium for sorting out confrontational issues. Neither the e-mail nor any mail will be able to convey the meaning in a way a person explains the same words in person; because the facial expressions as well as the body language make a lot of difference. In the case of e-mail, it is well known that it is not secure and so any difference of opinion expressed over the Net may be tapped by the competitor to take the customer away from you, ie, e-mail makes a public event out of any disagreement.

Like in the case of Feud, this situation also will start affecting the software developers in the organisation. This kind of antipattern is known as, 'E-mail Flaming' or 'Blame Storming'. The refactored solution is to assume that each and every e-mail, is likely to end up being scrutinised by our competitors and so act accordingly. Moreover, e-mail sent without appropriate disclaimer may end up as evidence in the court of law. William Brown suggests that e-mail should not be used for the types of messages like, confrontations, criticisms, sensitive information, politically incorrect topics and legally actionable statements. It should be borne in mind that unlike the fax or telephonic conversations, which are like one-to-one communication, e-mail is indirectly a broadcasting type of communication because of its vulnerability to encourage eavesdropping.

The next one is different from the last two antipatterns described above. This one will deal with over-enthusiasm at the top level of a software development organisation. Sometimes, in order to attract the customers for downloading projects for development, even a small demo project is displayed and projected as the end skill of the capability to undertake complicated projects. It does not even stop at this; the misconception may lead to making commitments beyond the expertise of the company. A customer downloading a project to such an organisation will be the ultimate loser, if the end product does meet the specified functions and quality. Such a product, as we have discussed in an earlier article, will be a typical example of the so-called stovepipe system with all its inherent problems to maintain. The antipattern arising out of this situation and is called, 'Smoke and Mirrors' and 'Vapourware', because the customer is made to believe that he will get what he wants. The refactored solution is-every organisation should realise that a deliverable system takes more time and money, and demand much better quality aspects than the prototype. The rule of the thumb is that it is better to make the customer expect less than can be delivered because when we provide more than what is expected it will induce the customer to come back for future developments.

  ( To be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)