Appendix A: Teamwork

---

Overview

Up until now, we were primarily focused on the individual programmer and techniques he could use to improve his performance. There was less discussion of the interaction between programmers. Because the majority of programmers will find themselves working in a team environment, it is important that programmers be able to interact with other programmers, other members of the developer’s organization, and in some cases, the customers and end users of the product. This short introduction to such an extensive topic is intended to just get you started thinking about the effects of team dynamics on software development.

Made for People

While deep in development, it is easy to forget that the final product will be used by other people. It is also likely that the users will not be programmers, which means there are several considerations that can easily be forgotten. Communication to the customer is a key area from the very beginning of development. The average customer will not understand the technical issues involved in what they are asking for in a product, leaving it up to the developer to provide a basic understanding of the limitations that might be encountered during development.

Customers will not like to hear that their requested features cannot be implemented, and can easily turn to another developer if they feel the reason for this failure is a team’s incompetence. To combat this possibility, it is important to have a list of alternatives available when presenting the limitations. Alternatives can include similar features that are substantially easier to implement, or budget and time changes that would provide the necessary resources to implement the feature.

This communication is not limited to the beginning of development, and becomes particularly important if unexpected problems arise later in development that place a feature in jeopardy of not being implemented. Customers will respond much better to clear explanations and a variety of choices than they will to stories of woe and confusing technical explanations.

Buffering the communication between customer and developer with a layer of management on the developer’s side can be either a benefit or detriment, depending on the circumstances. If the manager is both technically knowledgeable and capable of translating the technical details into easy-to-understand terms, the situation is optimal. Otherwise, it is still up to the technical developer reporting to the manager to place the explanation in understandable terms. However, even if the manager is not technically knowledgeable, he can concentrate more on communicating with the customer to build a strong rapport that will make the exchange easier. At some point, though, there will need to be a translation from technical terms into layman terms.

The other major consideration is how the customer affects what choices are made during implementation. In a manner of speaking, the dialogue between the customer and developer continues even after the product is finished in the form of the end user using the product. The end user, and therefore the customer, is only concerned about the elements that he can see and hear. A slick implementation of a particular algorithm is only useful to the customer if the effect is visible on the final product. Thus, one of the considerations in choosing an implementation is the visible effect it will have on the product in the customer’s eyes. However, do not forget that development time is also visible to the customer, so implementation decisions meant to decrease development time are also very valuable.

The main point is that the goal of the product is to impress the customer and end user. While nifty algorithms might impress fellow programmers, and cool technical terms can benefit marketing somewhat, an application that meets the user’s needs effectively and efficiently will provide the most impact. Except for academics, most programmers must remember that they are part of a business. Even for academics there is often politics and funding to compete for, and these require some of the same attention to the target audience that is given to the customer in commercial products.

Made by People

Another fact often overlooked by developers is that people are making the software. A developer is not a black box that takes a list of requirements and magically produces the product. Humans, with all their quirks and oddities, are a key part of the process. Understanding this is a key part of avoiding problems and delays caused by the personalities involved in development.

The most important factor that the human involvement brings to software development is the need for communication. Even with the advanced capabilities of human language, there is still plenty of opportunity for communication failure to cause problems. Knowledge of these common failures can help avoid them, just as knowledge of common programming mistakes allows those mistakes to be prevented. Shortly, we will look at the importance of different viewpoints on communication, but for now let us look at the other effects of communication on development.

Apart from the point of view that affects the communications of team members, other human biases will also affect what and how people choose to communicate information. Before assuming that another team member is stupid or stubborn, consider how his personal bias and career history might be affecting his decisions. Not only will this reduce your level of frustration, it will allow you to prepare a better argument to change his mind if you still believe he is wrong.

Just as the customer and developer can have different technical knowledge, so can individuals within a developer. Some people are better than others at communicating between different groups, and understanding who they are on a team can avoid confusion. Both sides, technical and non-technical team members, can take advantage of these people in order to aid communication within the developer. This will reduce frustration that typically comes when two people with disparate technical experience attempt to communicate technical issues.

If the developer is a large organization, another danger is the number of people involved in communicating any one piece of information. The more people the information travels through, the more likely it is to be distorted or misunderstood. In addition, response time is reduced, sometimes to the point where vital questions are not asked because of the difficulty in getting timely answers. E-mail and other permanent forms of documentation can help reduce communication errors. Whenever possible, passing along the original communication unchanged, along with any annotations, is best for ensuring that the destination party fully understands what the source of the communication meant. Response time is improved by determining which parties require direct communication on a regular and timely basis. This communication should be established and encouraged unless there are personality issues involved that would cost more time than the faster communication channel saves.

Another important consideration in working with people is the need to prepare for occasional mistakes and poor decisions. Even the best programmers introduce bugs into code and choose the wrong path on occasion. The difference is in how well prepared the team is to detect and handle these errors. Proper testing, peer reviews, and a willingness to consider oneself fallible go a long way toward minimizing the impact of errors. In other words, do not attempt to eliminate all errors; rather, attempt to minimize their impact.

Point of View

Different members of a team have different, sometimes opposing, stakes in the outcome of the project. Understanding the point of view of other team members can assist in both communication and decision-making.

Management

Programmers have the most difficulty understanding management. The motivations of the managers, which are primarily focused on business decisions, often differ from those of the programmers and other developers, which are primarily focused on the technology and creative aspects of development.

In order to be persuasive when talking to management, a programmer must remember these motivations and present his ideas in terms of these motivations. For example, when suggesting the purchase of a third-party library, show how the schedule can be reduced to save more money than will be spent on the library. If a feature cannot be reasonably completed, explain how much extra time and money would be required to complete it. In addition, offer alternatives that might provide a reasonable replacement at much less cost and time. Do not be afraid to ask which areas are most flexible for the customer and management: time, cost, or features.

Likewise, look at requests from management in terms of the customer and business concerns. Some features might sound meaningless, but the customer might have some reason for the feature and management is asking you to implement the feature to keep the customer satisfied. Nothing useful is accomplished by returning with a refusal to add the feature. A better approach is to inform management of the costs of implementing the feature and any tradeoffs that will be required. If they are willing to accept those costs, but you still have reasons for believing the feature is detrimental to the product, present your concerns as concerns for the product and suggest alternatives that will still satisfy the customer.

As always, keep in mind that you should think about the request first, but everyone can make mistakes. If you believe a mistake has been made, present your arguments rather than refusing without a good explanation. This might seem obvious, but it is easier to forget to do this than most people think.

Team Members

On the other side of the equation, it is important for management to understand the point of view of the individual programmers and other individual developers. To many of these individuals, the technical merit and correctness of the application will be more important than esoteric business concerns that they might not even know exist. Some of this can be overcome by explaining the business reasons for a request. With a better understanding of the reasoning, you might find that some programmers become less reluctant to perform operations that go against their first instincts.

When the reasons still do not convince the programmer, be sure to listen to his objections and get feedback on the impact to both the application and the schedule of the requested feature or change. In addition, listen to any alternatives. Once you have this feedback, you are in a much better position to decide on these alternatives or explain to the programmer that you are willing to accept the tradeoffs.

Coworker

Finally, do not forget that even your coworkers have different ideas and motivations than you do. If you do not understand why they are implementing a piece of code the way they are, ask them for an explanation. In so doing, you might learn new concepts and techniques, or you might have an opportunity to point out concepts or techniques the other programmer did not consider. Thus, instead of wasting time and becoming frustrated, the project will progress smoothly and ideas will be shared.

This is of course the ideal, but reality must occasionally disrupt this programming utopia. There are programmers who are not capable of the proper level of performance to be a member of a particular team. There are also programmers who are disruptive to the morale of a team. While a certain amount of patience and tolerance is essential to a team environment, managers must realize that some relationships will not work and the relationship must therefore be ended. As with so many other aspects of software development, and life in general, maintaining an efficient and skilled team is a matter of balancing the different forces at work.

---