Log in

No account? Create an account
Previous Entry Share Next Entry
Communication Media and Social interactions in projects
I have a lot of things I want to publish here, but not enough time in the day to write them all. However, this one particularly struck my interest.

I'm interested in communication between people. This is part of the reason that I find LiveJournal and other social networking software so interesting - it shows relationships between people simply, and allows communication between them as well. (And if you think LiveJournal isn't social networking software, you don't understand the term: Building relationships and the results of them is a huge part of this site.)

There are a number of different ways that I communicate with people around me. The first is the people I'm physically close to: people who live on campus and near me, that I can actually see in real life. This method of communication is good in lots of ways - quick, face to face discussions can achieve a lot in the ways of interpersonal relationship building. However, it doesn't work very well in technical situations. You can't teach people how to program in a face to face situation. Spoken language can't convey many of the technical needs that learning non-spoken languages requires. Spoken language is great for relationships, but not for technical discussions.

The same applies to phone conversations, but even more so. In a conference call, you can discuss ideas, you can toss around plans, but you can't actually get down to the meat of implementation. I'm likely biased because that's where my work centers, but I'm a coder, and you can discuss high-idea plans over my head all day, but until you get down into telling me what the next feature to code is, and suggestions for coding it, I'm just going to sit and twiddle my thumbs.

Online communications are where this kind of thing. In group based online communications, there are a number of different ways of working through things. Some of the communications methods I use are email, IRC, and wiki-based information storage.

IRC is similar to phone conversations in that it's designed more for social and discussion based issues rather than coding. However, the ability to say "Let's take a look at line $foo in my patch at [link]" and actually discuss function calls, variable naming, and similar topics makes it a quick real-time medium for discussion of possible issues. Implementation ideas can be discussed, and then everyone can just kind of hang out and hack.

E-mail is one of the best methods for patch discussion. Technical patches can be attached, with long explanations of why things are done the way they are. At the same time, you get the group aspect with things like mailing lists, and you can discuss issues back and forth all day. Not the best way to build social relationships, perhaps, but a great way to hack on code. Bugzilla based systems are simply extensions of this - they allow you to do patch-level discussions in a mailing list format, a truth accentuated by the fact that many of Bugzilla's features are based around email and sending it out to people who want it. This is one reason why Bugzilla is a great system even in small setups - it's the forefront (as far as I know) of issue and feature tracking software.

Wiki based storage is great for a lot of things - documentation, general plans, outlining of todo lists, and so on. Wikis are much more of a form of permanent storage - slower than any of the previous methods mentioned, even with things like RSS feeds for Recent changes. Socialtext workspaces avoid this a little bit by creating mailing lists of recent changes that get sent out on a regular basis, keeping people up to date on what's changing in the workspace. However, the social aspects of most communications are almost completely gone.

Social communications exist in many aspects of almost all projects. Whether you're talking real life, phone, IRC, or email, there's always drama. (If you think that things like Zilla avoid Drama, just see some of my discussions with marksmith from a couple months ago. ;)) Wikis avoid this, obviously, but are clearly more of a form of permanent storage rather than an interactive communication medium. For idea discussion, real life or phone is best, but for patch discussion, email is the place to be.

Some people try to separate the social aspects of working on a project from the technical aspects. The idea that this can be done while achieving any kind of reasonable productivity level is ridiculous - you have to be able to interact with the people you work with to get anything done. This is part of the reason why people like bradfitz don't make the best project managers for large scale projects. He works pretty well on things like memcached where he's the maintainer and the largest contributor to the code, accepting patches from people who have a high level of technical skills. That kind of project is much easier to deal with, because the people act in a professional way - which many people who volunteer their time for LiveJournal do not. They (and I include myself in this) seem to have some kind of expectation of having their code looked at by people who can accept it - and when code is bad, many people don't have any desire to look at it. Managing a project with patches from people who really don't understand the technical aspects of the code they're patching is frustrating, and difficult to work with.

I'm a code monkey - I don't do management well, I'm a drama queen (or have been in the past at least - I like to think I'm starting to move past that), and I'm not the best at interacting with people. But interacting with people, through many of the media describe above, is necessary in so many cases that to ignore social interactions in a project is simply ludicrous.

  • 1
I don't think of you as a drama-queen. I think of you more as someone who expects everyone to *gasp* live up to your standards.

This runs counter to my experience in so many ways...

I've programmed in offices, I've pair programmed, I've programmed on teams over the net, and I've managed teams over the net. I'll take the office (or pair programming) any day. In my experience, face-to-face contact can easily be an order of magnitude more productive than hashing things out over e-mail.

There's a tendency to over-analyze e-mail, writing a couple-page response filled with code examples where a simple "This is what this should do" would suffice. There's an attendant time-lag too; because you want to respond to all aspects of the design that need responding to (to avoid ThreadMess), e-mails become long, involved design documents.

On a whiteboard, you can draw little pictures, say "This system needs to talk to that system", "Here's the information I need to know", "Here's the contract of this method", all in less than an hour. I've worked out week-long coding problems in a half-hour whiteboard session, after which we spent the rest of the night coding and had it working when we went home. I've also had database schema decisions that would've taken a couple hours on a whiteboard end up taking a whole summer of back-and-forth e-mails.

Are you familiar with pair-programming? Two people, sitting at one computer, looking at the same screen. It works surprisingly well - I found my bug rate dropped dramatically with another pair of eyes watching, and the code became much clearer. Variable names get clearer, and you eliminate much of the need for comments. That's obviously something that can't work over the Internet (though some folks have tried, with VNC and such).

Personally, I think BugZilla is fine as far as it goes, but is far from the ultimate in bugtracking. The ideal setup is simply to fix bugs as they come in (there's a rather contentious debate about this). Impossible, you say? Not if the code is well-factored and all developers know their way around it. Paul Graham describes fixing bugs in ViaWeb while the customer was on the phone, so that he would simply ask them to retry and the bug would magically disappear (Lisp lets you load new code into a running program). I've had similar experiences, where a bug fix took me all of 15 minutes. 'Course, I've also had experiences where a bug fix that took me 15 minutes introduced a bug that took 2 days, so YMMV.

One more moderate approach is to capture bugs with tests. I think this is somewhat more practical, and it also gives you automated regression testing so you know if you've broken anything. To my knowledge, LJ doesn't have any unit tests, so this may be unfamiliar to you.

Wiki is not a means of permanent storage - I run into this all the time when I'm refactoring pages on the C2 Wiki. It's a means for capturing evolving consensus. The content of a Wiki reflects good ideas of today, not a past history (except in rare cases that probably ought to be refactored). That's the big strength of it - you don't get bogged down in information that's wrong or out of date. But that's a development tool, not a documentation respository.

The real permanent storage is CVS. That's where you keep all your important documentation, and more importantly, code. The ideal place for documentation is code, because it's guaranteed to be up-to-date with the implementation. While I don't believe you can capture everything in code like XP suggests, I do think it should be the first resort.

You always tend to say the things I want to say better than I do. ;)

Part of the reason that I skip over the in-person formats is simply because I have no access to them on a regular basis, so they don't play a large role in my mind. In the limited number of times I have had face to face interactions with coding, they haven't typically been hack sessions - although I'd love to do way more of that than I do - and more of "idea discussion", which really doesn't lend itself to the situation.

If I could sit down in a room with one or two other people and computers for each of us, I think I would be majorly productive - but with the way that things tend to work out, that just never happens with me. I'm not saying it wouldn't be a productive environment - I'm pretty sure it would be - but the type of projects I work on don't seem suited to it. Part of the reason of this is that as an outsider on most projects, I hate closing things up, and as little as that may be the goal, interactive programming does that - you don't put in comments, because "everyone" knows about the way things work.

I do agree that the bug tracking issues you mentioned are important - get rid of bugs before you do new things is something I always like to see, which is part of why developing on LJ is so frustrating. "We just turned on phone posting." "What about the patch I submitted 6 months ago to fix $brokenaspectofthesite?" "Oh, we don't really care about that."

Capturing with bugtests was something that I hoped to do at one point - Brad has called again and again for a full regression testing suite - but never really took the time to do it.

I'm not sure how I'd work in a real time face to face environment. Personally, I often work best by myself. However, at the same time, having a second person there is nice. I've done the second (and third, in this case) pair of eyes on the screen - and it helps a ton, in the ways and for the reasons you said.

Wiki being permanant storage was a relative term compared to email or IRC - it's a way of putting up goals, tasks, etc. in a "current" non-volatile storage format, I think.

Part of the reason that we feel differently about this, I suspect, is that I'm very much an 80% guy - get the 80% of it done. This isn't to say that I don't do the other 20%, but it does mean that I have a very "get it done" attitude that probably doens' tfit with most of what you do.

I think hacking is a task that is often best suited for "alone" cases - discuss the issues, split up, come back with problems. Ideas are best discussed in person - as are problems. Come back to a group and work out what didn't work would probably work best.

I'm just too used to working alone to know what the right way to do these things is, I think.

  • 1