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.

Have to agree

[notamac]

I'd always thought that a number 2 would be for the best, however after working a few months in a number 1 for the first time... I have to say I'm liking it. So long as those interfaces are nice and narrow, and well defined (the code I inherited is like that now ;)), then everything just seems to work out for the best, and there's far less knocking of heads day in day out - and very little chance of producing a 3 (my previous employer!)

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:My answer, based on my experiences

[fiftyvolts]

One of the issues I think is that if you incorperate a certain level of sophistication into your code then people who can not program to that level think it is much too complex.

Take perl for example (mostly cuase you said ick ;-]). Perl is highly idomatic with "More Than One Right Way" to do things. Simple perl code is simple and easy to understand; however, the uninitiated will find it next to impossible to understand how the "magic" of some perl modules works. Modules that use things like glob refs, tied data structures, export, and eval to achieve great new additions to the language in ways that seem impossible.

To developers who are used to such things the code would look like an elegant, compact solution. To somone who doesn't it would (quite seriously) look like trash.

Re:It's all about people...

[duffbeer703]

Super programmers often hurt a team more than they help.

Alot of brilliant engineers and programmers are brilliant for a good reason: their brains are wired to intuitively grasp what mediocre programmers need to explicitly think about.

There's a downside to that as well; namely that those individuals do not have the best communications and personal skills.

Re:It's all about people...

[dmorin]

But how do you define "best people"? That's sort of the question, isn't it? Where's the magic set of interview questions that finds these people? Back up one step -- instead of trying to find people with X skillset, what *is* X skillset? Just coding? Communication? Management? Personality? Intuition?

That's really what the question's about. I think everybody wants the best people on their team. There are even best managers, because managers do actually add value (normally as gatekeepers to keep economics and politics away from the engineers).

Re:It's a matter of brain mapping, really

[HeyLaughingBoy]

will look like unmaintainable trash to most other programmers

Unmaintainable trash is *not* good code. Not in a team environment anyway. Hell, even when I'm doing stuff only I will see, I write it in a maintainable fashion because I already know that I'm going to revisit it in a year (whether or not I plan to!) and I really won't want to spend half a day trying to figure out what I was thinking.

I agree with you on option 1 except as stated above and I'd loosen up the code ownership a bit.

Coding standards exist for a reason.

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.

Re:It's a matter of brain mapping, really

[andy55]

They can make very hard, well-documented interface delineations between single-programmer-sized pieces of the project and essentially have a bunch of subprojects run by individuals that again look like unmaintainable trash,

It depends on the rev of the code. If the team is entering serious uncharted waters (which is what I deal with regularly), the first draft is code is better to be running than intensely structured (and take twice the time). This is all to say that you can't make a long-term, top-quality piece of software when you're entering on the first stroke. As the saying goes, "expect to throw your first attempt away" (someone please correct me w/ the right quote if you know it).

IMHO, I'm a big fan of the "surgical strike team" approach to development, but then again, our software happens to be on the outer rim of typical software. Also, the "surgical strike team" approach is a more realistic one when you're talking about a small company that can't afford to have lots of devs (and only has one or two "think-tank" devs who wear a lot of hats and can't spend weeks writing specs on concepts that are only first or second generation).

It works at different levels

[Jare]

- The first tier is functionality: does it do what it's supposed to do? - The second tier is reliability: does it perform its functionality in an efficient and foulproof way? - The third tier is maintainability: is it easy to modify for changing / new requirements? - The fourth one is adaptability: can it be reused in other projects that require the same functionality? Hotshot / smart programmers usually get the first one done quickly. Professionally-minded programmers usually get the second one right. At that point it usually feels that the job is accomplished. Experienced programmers can make the third and fourth happen. "Good programmers" (smart, experienced and with good attitude) can get 3 or all 4 done. "Newbie" programmers need guidance and double-checks in order to get any of them accomplished. When this happens under a good lead or with a process that ensures the output is truly the sum of the qualities of all team members, it is much more easy to happen at all levels. "Process" relates to communication (documentation, reviews, etc) as well as discipline (enforcing standards, etc). Boiling it all down to "communication" is both correct and woefully incomplete / imprecise.

Re:My answer, based on my experiences

[YankeeInExile]

Until next year when programmer #2 who does know how to spell works on your project (or, in your case, you yourself learn to spell), and types make and hits return harder and harder and curses you out loud, because he has to remember to misspell caffeine precisely the same way you did in every place.

Then, one day, he will get tired of it, and S&R the misspelled version with the non-misspelled version, and blood pressure will be relieved.

One metric of a programmer is "how much time transpires between beginning modification and fixing some stupid little cosmetic problem that is driving him nuts." Feel free now, to include by reference the entire "color" vs. "colour" flamefest from lkml.

One habit I have had to force myself to break, is to re-idiom code to match my personal habits. Or, more accurately, refining the change it or leave it? decision process.

A little snippet of a conversation I had with one of the other guys I work with:

• me:...I kind of regret that inteface - I was not sure it was the right thing when I wrote it, but now it is too entrenched to rip out, but it defintiely is not the right thing
• him:Don't sweat it too much. Great programmers are always wracked with regret. It is the crappy ones who never look back.

Keep developers apart

[Anonymous Coward]

One of the most productive and successful projects I've worked on was an embedded system where I was doing (mostly) software, and another engineer was doing (mostly) hardware. I worked "normal" business hours, in my office on the 23rd floor. He liked to work "night shift" in his hardware lab in the basement. Thus, we almost never saw each other, or had the opportunity to communicate directly.

What we did do was communicate entirely by email, knowing that any questions would take a day to get answered. The fact that everything was through email provided a wonderful audit trail for the entire project, and the fact that we couldn't get instant answers to questions encouraged us to "think through" our questions before sending off an email about them. Often, the process of writing up a lucid question would force us to figure out the answer (or at least understand the question better) on our own.

When I turned over the project to another developer for maintenance, I was able to give him the archived email messages as a complete history of how and why we developed the project the way we did.

Of course, this is the norm for open-source developers, but it was unique in the corporate environment in which I work.