Software Development Hypothesis

Hypothesis: The inter-team communication requirements when doing distributed software development force better communication habits upon everyone, which can lead to an overall better development process.
Explanation: When a group is working together in an office, a majority of communication happens verbally and generally informally (ie. talking in the halls or in meetings). These communications are generally not recorded and archived. Knowledge is lost and/or spread unevenly among the group. With a modern distributed development group, the majority of communication is forced to be text, through email, IM, chat rooms and wikis. The knowledge is (within the limit of the tools) easily accessible later, by the entire group. What would seem a disadvantage, that of not all being together in the same building (or even in the same time zone), ends up being an advantage.
Agree or Disagree?

17 thoughts on “Software Development Hypothesis

  1. True.
    But there is something to be said for that in person communication. A lot can be conveyed between people and other things such as brainstorming in front of a whiteboard. People still go to work in central offices for a reason.
    But once you can recognize that (the reason why you meet in person) you are able to value and prioritize that time. It will then benefit other things such as telecommuting. Say, coming to the office 2 days of the week.

  2. Agree. Its how most open source projects operate. In Apache, its commonly said, if it didn’t happen on the mailing list, it didn’t happen.

  3. I agree. The quality of the documentation of a distributed team will be higher. What this doesn’t take into account is the quality of the communication, which in the distributed team is far lower, and thus the distributed team will progress more slowly.

  4. I agree.
    But if I had to chose between try to improve the inter-team communication locally or make the team distributed to achieve that, I would go with the first choice.

  5. Agree.
    The process is largely self documenting.
    Ivan: Your team doesn’t need to be distributed to take advantage of some of the distributed forms of communications.

  6. I disagree that the added formalization of communication makes up for the lack of bandwidth and group mojo when dealing with a distributed team. I’m sure it depends on the project, but in my experience whenever we’ve taken external developers/partners and brought them in-house we get an order-of-magnitude improvement in communication fidelity and speed, and few projects have really clicked when we didn’t figure them out in the same room together. js

  7. The distributed communication documentation effect doesn’t ‘make up for’ facetime mojo, its just different. The group effectiveness depends on how well they work with the system in place. I happen to prefer the distributed method, others would not.
    More important for effectiveness for either valid communication style is if the team has shared attitudes, professional interests and that they’re smart.

  8. I would agree, although I would wonder if it’s a cause or effect. Is it that the successful distributed developer groups we hear of often already have decent communication skills, or did their skills actually develop as a result of the remote nature of the developers?
    I do think it would help some people. I’ve worked for small groups where people seem to forget that conversations they’ve had, decisions they’ve made, have only been with a few other people out of the group, and since it’s a small group, their mindset is, “Well, we just talked, so why should I write anything down?” and completely forget there are some people in the group who were not involved in the discussion.
    The worst case I’ve found is when there’s a small group and only one or two people are working remotely (or even just working from home some particular day). The person working offsite is definitely left in the dark about most things, because they’re “out of sight, out of mind”.

  9. Agree, to a certain extent. I think it depends on personality styles. For an extrovert, these informal encounters, (water cooler chats, etc), are energizing and the personal contact keeps them motivated. They will tend to more easily store the information when it’s gleaned by personal contact.
    For more introverted types, communicating by electronic media is preferable and they tend to like to be able to quietly go back and refer to it later, on their own time. They think better when alone. So this kind of set up would work efficiently for them.

  10. Disagree. Having conversations, notes and decisions documented in several media (email, IM, wiki and of course, the spec) makes searching hard. Email and IM in particular aren’t necessarily available to the whole team, and wikis can be confusing to navigate. If the team has an good PM who can take care of organising all this, then it could work, but I think a single, updateable reference is better than a collection.
    The advantage of verbal conversations is that ambiguities are easier to spot and discuss, and decisions are generally recorded anyway. Getting to know someone is easier when you can be with them, and this builds trust and understanding a lot quicker than electronically. Communication is more than just words – it is also about body language and facial expression.

  11. I don’t agree that the communication is necessarily forced into those venues… I have encountered people who for one reason or another don’t take to written communication and therefore insist on having a phone call for anything that can’t be expressed in a single sentence.

  12. Agree! I’ve thought a lot about this, and I think having archives of all the development-related communication is a very important asset.

  13. I’ve found there are a lot of people who just refuse to read emails, and instead skim them, giving a one or two sentence response. A paragraph if I am lucky!
    I don’t know how much better software dev. professionals are in this respect, but I can’t imagine that they are much better.
    If there were better, ready-to-go datamining solutions for collating data from im, email and possibly web forum all together, along with great search capabilities, it might work out alright.
    My preference would be to have everyone set up with laptops and or 2 monitor stations at a big conference table, with some cubes surrounding for taking client calls and/or super-concentration tasks.
    There are a million little decisions that need to get made, a million little questions that don’t work well in email or chat. A quick question answered in person can get you back to work in seconds rather than (best case scenario) in minutes.
    If folks commit to answering IMs within a couple of minutes, I’m not sure whether it would be any different than a face-to-face enviro., with the benefit of recordability.

  14. I think distributed works if the team knows how to work in that environment. It requires a certain level of discipline by all people involved.
    I disagree with the ‘put everyone on a conference table’. That is good for fun events, but not for the long haul. Interuptions are the number one productivity drain for software engineers.

  15. My collegues and I are working in the same office, that’s why we have verbal communication. But for sure we experience such ways as e-mail, ICQ, some chats just to show something to each other.

Comments are closed.