Title: Professionalism in Programming #34

These are influences that will determine the effectiveness of a software team, and the quality of the work produced. For effective teamwork, all of these factors must be in place:

In contrast, these are sure indicators of a team that is not able to work effectively. Note that this is a mix of internal and external factors.

Teamwork is dead without communication. Individual parts cannot move as a whole without communication. How can the goal and vision be shared without communication? Projects really do fail because of a lack of good communication.

Intra-team communication occurs in several ways: conversations between individual engineers, phone calls, meetings, written specifications, email correspondence, reports, and instant messaging. Sometimes we even communicate in pictures! Each medium has a particular usage dynamic and is most appropriate for a specific kind of discussion. The most effective communication should involve (or at the very least be visible to) all relevant parties. It should be sufficiently detailed, but not consume too much time or effort. It should be performed in a suitable medium - for example design decisions should be captured in a written specification, not agreed verbally and shared by word of mouth. Code itself is a form of communication. A programmer must be able to communicate well. This requires both good input and good output:

In addition to intra-team communication we must also consider communication between teams. The classic example of bad communication is seen in most companies, between their marketing department and the engineers. If marketing don't ask the engineers what is possible then they will sell products that the company can't make. This kind of problem is cyclical: once it has occurred once and people have been burnt, the two teams are less likely to talk to each other (due to resentment). It will then happen again and again.

Best used for communication that requires an urgent response, a phone call interrupts what you are doing. For this reason it's inconvenient to be called for non-urgent matters - use another method instead. With mobile phones we are far more connected than we used to be; this is a blessing and a curse at the same time.

Being audio only, you can't see the other person's face and their subtle body language cues. It's easy to misinterpret someone on the phone, and draw a different conclusion from the other person.

Too many techies are scared of using the phone. Don't be - for urgent communication it's invaluable.

An asynchronous, out-of-band communication medium. You can specify a level of urgency, but email is never immediate - it's not a real-time conversation. It's a rich medium, allowing you to quickly send attachments, and compose replies when it's convenient for you. It is often used for 'memo'-style broadcasts to many recipients. Your email history provides a reasonably permanent record of communications. Email is an immensely powerful communication mechanism.

You must learn to use email as a tool, and to not become a slave to it. Don't open every new mail as it arrives; your coding will get interrupted far to often, with a hit to your productivity. Designate email reading times, and stick to them.

A quick, conversational medium that requires more attention than email, yet one that can be ignored or sidelined easier than the telephone. It is an interesting and useful middle ground.

These are less conversational than email communication, and more permanent. Written reports and specifications are formal documents. They take longer to prepare, and are consequently harder to misinterpret. Written reports are generally reviewed and agreed on, so are more binding.

This is an essential characteristic, and so often lacking in our profession.

The humble programmer wants to make a contribution to serve the team. They don't slack off to let others do all the work. They don't believe that they are the only talented person capable of making a worthwhile contribution.

You can't hoard all the 'good' work for yourself; it's just not possible for one person to do everything. You have to be willing to let another team member contribute - even if it's something you want to do.

You should listen to and value the opinions of other people. Yours is not the only point of view, and not the only solution. You don't necessarily know the only, or the best way to solve every problem. Listen to others, respect them, value their work and learn from them.

We have to be realistic: some people can't help winding each other up. In this situation we must be mature and responsible in our attitudes, and learn to avoid (or learn to resolve) conflict situations. Conflict and animosity breed more and more bad will, and will severely degrade the performance of a team.

However, harnessed and channelled conflict can be a major success factor in your team work. Team mates who stimulate and provoke each other produce the best designs. Disagreement can act as a refining process, ensuring that ideas are valid. Knowing that your work will be cast under a critical eye keeps you focused.

It's important to keep this kind of conflict constructive; on a strictly professional, not personal, level.

This doesn't just mean learning new technical skills, but learning to work as a team. It's not a God given gift. A new team has to learn how to work together, how each member reacts, their strengths and weaknesses, and how to capitalise on individual skills to the group's benefit.

Emerson wrote: "every man I meet is in some way my superior". Look at what you can gain from your peers. Learn from what they know, learn from what they're like, and learn how they react. Learn to communicate with them. Seek criticism from them at all levels, from the formal code review to their passing opinion offered in conversation. Good teamwork builds the project and also builds the team. An important part of 'building the team' is for each member to be learning as they work.

This is tied closely with learning.

If the team has a need that no developer can currently fulfil, and it's not possible to bring in an outside resource, then a solution needs to be found. Adaptable people can learn the new skills quickly to fill the gap and serve the team.

If you are committed to work that you know you can't do, or later find out that you don't have the skills to complete (and you can't realistically learn them in the given time scale) then you should make your manager aware of this as soon as possible.

Otherwise, you will fail to deliver your piece of the project, and the whole team will suffer as a consequence.

Many people believe that admitting they can't do something is a sign of weakness. It's not. It's better to admit your limitations than to be a point of failure in the team. A good manager will provide some extra resource to help you do the work, and along the way you will learn the new skills that you previously lacked.

Having investigated the core personality traits and essential skills of a team-playing software developer, we can now investigate what tools help us to form a functioning software team. There are a few indispensable tools that facilitate collaboration and help to elevate your joint development from chaos to a well-oiled machine. On their own they won't make you a team of commando programmers, but they're the arsenal every crack outfit relies on - the prerequisites for effective software developer interaction.

Even if you're the sole developer on a project, you need a source control system - it's a crucial store of the codebase and its history. When there are multiple programmers it becomes even more critical. Source control helps to marshal who is doing what and when, provides the definitive 'latest code' snapshot, and allows you to manage changes, undo mistakes, and make sure that no one misses source code updates.

Without it you'd need to employ someone to integrate all changes and manage the code. And they'd be more likely to make catastrophic mistakes. Joint development without source control is unthinkable.

We've already looked at what this is, and the specific purpose it serves. However, notice how it facilitates interaction between your development team and the test team. A fault tracking system acts as a pivot between test and development. It helps to organise test and repair work, prioritise faults, assign problems to individuals, and track pending fixes in the software.

The tool can be used to make sure that all issues are addressed and that no work is overlooked. It makes clear which faults are currently development's responsibility and which are tests.

A team needs effective communications support, especially when geographically split. A centralised calendar, address book, and meeting booking system provides a digital administrative backbone.

You also need a mechanism to share documents, both externally supplied documents and your current works-in-progress. A groupware tool facilitates such collaborative work. Without this facility, an inelegant replacement is a well-defined shared network drive.

There are other tools that facilitate group interaction. Consider using wikis (web-based community documentation tools) and internal newgroups (email discussion boards with more permanent storage).

It's important to establish a defined and universally understood development methodology, or work will be chaotic, performed on an ad-hoc basis. One developer will release their code, when another would refuse to let go of it until they've thoroughly tested and debugged it. One developer will halt all coding until they've produced an intricately detailed specification, whilst another rushes straight into prototyping the code. Holy Wars are made of smaller things than this.

A methodology defines the development process details, who is responsible for what work, and how work is handed on. With one, every developer knows how to work as a part of the team, and what's expected of them. You must pick an appropriate methodology, based on the size of the team, the kind of code you are producing, and the talent, experience, and dynamics of people.

To produce any work in a predictable, timely manner you need some semblance of organisation. This is enshrined the project plan, detailing who is doing what over the course of development. To be of any use, the plan must be based on sound estimates, stuck to by developers, and kept up to date with any changes required.

The structure of a software development team is shaped by two main factors:

This will determine the amount of code and the size of the units that you work on. The code produced, in turn, is shaped by the organisation of the team.

A project may be managed on a peer basis, with no coder considered more important than any other, or under the leadership of an über-programmer/manager. The programming team could be considered part of a software production line: fed designs from a team upstream, they produce code to specification^[1]. Enlightened software engineers are given more autonomy and responsibility.

Tasks may be allotted months in advance, on long-range plans (which can rapidly become out-of-date and inaccurate), or 'just-in-time' by assigning each work package when a developer finishes their last one. Programmers might work alone on their individual parts of the system, or work collaboratively, pair programming to spread responsibility and knowledge.

The axis of responsibility determines how each line of development is split amongst programmers:

There is no 'right' kind of organisation. Which one is most appropriate depends on the team members and the nature of the work produced. The pragmatic arrangement is probably somewhere in the middle.

A team's organisation has an inevitable affect on the code it produces. This is enshrined in software folk law as Conway's Law. Simply stated: "if you have four groups working on a compiler, you'll get a four-pass compiler". Your code inevitably takes on the structure and dynamics of your interacting teams. The major software components lie where teams gather, and their communications follow the team interactions. Where groups work closely, component communication is simple and well defined. When teams separate, the code interacts clumsily.

We naturally aim to create opaque interfaces between each different team's work, to facilitate our interaction with that team. We do so even in cases where reaching into some internal part of another component might be valid and better approach. In this way teams can foster arbitrary divisions; despite our good intentions design decisions are forced by team composition.

Of course, there's nothing wrong with encapsulation and abstraction; however they must be designed in for the right reasons. If anything, organise your team around the code you must build, not vice-versa.