Software development as group activity

The stereotype of a software developer is a kind of loner cowboy who gets the job done.

What bugs me about this is that, occasionally, a developer will create something from scratch that the guy in the next cube built a couple years ago. Or the implementation will be ill-conceived, even though the best architect sits no farther than a paper airplane could fly.

This makes me appreciate Agile development. I find it gets developers talking, even if it's simply an extended version of, "I'll do this, you do that." Developers who talk about their work are more likely to generate new ideas or solve problems effectively.

Teams are powerful.

In my experience, the basic tenets of Agile development -- e.g., daily scrum, rapid iterations, burndown, backlog -- together provide a useful scaffolding for getting individuals to work as a team. The first time I got all the pieces working, I was actually amazed at how the team took off on its own. The individual parts of Agile practices actually serve as a metaphor for a team: each part can be ineffective by itself, but together they become very powerful.

I only wish for better alternatives to pair programming. The guidelines for pair programming seem oppressive -- switching pairs every 4 hours! I haven't yet met anyone who actually does it as specified, and I haven't been courageous enough to try it myself (nor strong enough to convince any of my bosses).

But I definitely like the idea of getting programmers to work even closer together.

Jeff Atwood mentioned a very clever idea (which he apparently had 4 years ago) for how to screen for developers who will be more inclined to work with others:

I have my own theory about the ideal way to interview developers: have the candidate give a 10 minute watercooler presentation to your team on something they've worked on. I think this is a far better indicator of success than a traditional interview. You'll quickly ascertain:

• Is this person passionate about what they are doing?
• Can they communicate effectively to a small group?
• Do they have a good handle on their area of expertise?
• Would your team enjoy working with this person?

This is absolutely something I will try.