Communication Within Programming Teams?

aldheorte asks: "If you are a developer you have probably, over your time on various development projects, seen lots of projects with really awful code and some projects with really good code. You may also have observed that sometimes the projects with really awful code have a few excellent developers involved, while projects with only intermediate or mediocre developers are able to maintain a pretty good quality of code overall. The lucky few may have even seen that legendary situation of great developers and great code. I have always been mystified by this apparent discrepancy and I think a recent article on CSS development in a team environment may hit the nail on the head: 'The quality of code generated by a team rarely owes as much to the skill of the individual members as it does to the level of communication between them.' I am interested in the experience of others here on Slashdot. Have you observed this discrepancy between individual talent and a project's quality of code as well? How much of the success or failure of communication is based on the members of the team themselves as opposed to the management of the team, especially with respect to allowed time and deadlines?"

Comments

Exactly my experience

[gerddie]

My former boss was quite good at writing his own programs. However, CVS was a no-no, design patterns never crossed his mind, and when he got some code from me and my colleques to put it in his library, comments usually vanished.
Now he is gone, and when we detect a bug in one of the old programs (that some of us still have to use) we usually start to refactor the whole thing, only to understand how it is working.
Writing new software now follows strict rules, and we talk a lot about how to do things. All team members are able to understand the code base (or so it seems) - unless maybe a very sophisticated template based compile time decisions shows up (then some brains just snap *grin*).
Since we are at an scientific institute where team members change quite regulary, transparent code is the only way to survive in the long run.

Tech Leads as information conduits

[dmorin]

One thing I've noticed on successful teams is that the best senior technical people are not those that put their head down and code like maniacs, nor are they the ones who stand in front of the whiteboard with the circles and the arrows. They're the ones that display an almost mystical ability to simply know everything that is going on in the team, and be able to redirect at will in order to optimize what's going on.

Part of this is being the listening board for other members of the team, which comes naturally as a result of being a senior member. But it also comes from always having one's ears open, without having to force your way into every conversation and say "What's this? What are we talking about?"

You'll know if you're doing it right because the world around you ends up feeling like you're in the middle of a giant coincidence. You hear two people talking about something and you say "Hey, I just saw a tutorial on that in so-n-so's blog" or the guy in the cube next to you says to anybody that's listening about a problem he's having with JSP and you shout back "Check with Ashish, he told me he was looking into something similar a couple weeks ago..."

Let stuff arrange itself in the background of your brain so that you can call it back when you need it. And then bring it up as needed, don't shove it down anybody's throats. You see an article that says Struts is out and Tapestry is in, you don't walk to everybody's cube and say "Hey, did you hear that Tapestry is the new thing?" Forward a link to the article to the team. The ones that want to read it, will. But then a month or two later when the boss asks whether you should go to Struts, then is the time to say "I hear Tapestry might be the better choice..."

Once upon a time I used to argue that hacking is understanding of the resources available to you, and creative application of those resources toward problem solving. Everything that you take in, be it what you did, read or heard, counts as "resources available to you."

What is a "good" programmer?

[Twylite]

How are "good" and "bad" programmers measured? Whether I'm doing paid-for commercial development or working with a team for free, my criteria for a "good" programmer is the same: produce code that performs its intended purpose, is reliable, and is maintainable. The question of maintainability includes considerations such as design (in the small), style, and documentation.

The idea that deadlines lead to bad code is a fallacy, and a self fulfilling prophecy. Code that is written well the first time has less bugs, which are more easily tracked down, and is easier to integrate with. Unfortunately those that cling to this mantra tend to believe that the only way to meet a tight deadline is a hack job.

Communication is important in code quality and in meeting deadlines. Communication provides a way to learn -- about better ways to do things, about how the program flows, about what utility functions are available, about how not to reinvent the wheel, and about who can give you a quick answer to a problem that may require half an hour of searching through a large code base. All of which contribute to better code and greater productivity.

Most important, communication allows a team to inform a member who thinks (s)he is somehow special or better, that "programming" and "software engineering" are different disciplines, and that the latter is required for long-term success.

Yes

[aristus]

I had the pleasure of working under a truly stellar programmer. Through braindead bosses and vauge requirements he built a system that worked *and* scaled 100:1. Comments were rare but almost unecessary, because all of it was astonishingly consistent. Many a time I was working on the code, wishing for a lib that would... oh, wait! It's already written. 500%? absolutely. He had to be replaced by 5, count 'em FIVE people.

Re:Define good code

[titzandkunt]

Good code, in no particular order:

Fulfills the specs, no crashes, leaks, etc etc etc, obviously.

Reuses, and is reusable, where sensible (making a religion out of reuse is as bad as no reuse IMHO)

Is comprehensible to the rest of the team (but maybe not on first inspection)

Is documented (Javadoc stylee, for preference!)

Sparse, to the point where nothing can be taken out (without deteriorating into an obfuscated C entry. The rest of the team still have to understand it)

Just one man's opinion.

T&K.