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

It's a matter of brain mapping, really

[photon317]

Almost invariably, unless the really good programmer puts an uncommonly high amount of effort into such things, the output of a single really good programmer will look like unmaintainable trash to most other programmers, especially mediocre ones, which are the norm in the industry.

This isn't because he writes bad code, it's because he naturally programs in a way that suits his brain, no tin a way that suits other peoples' brains. When code is written by a team collectively, they have three essential options:

1) They can make very hard, well-documented interface delineations between single-programmer-sized peices of the project and essentially have a bunch of subprojects run by individuals that again look like unmaintainable trash, and nobody can work on each others' code.

2) They can communicate effectively and code to a common standard of thinking and style. Essentially you're finding common ground between all the brains involved. This tends to need to be a lowest common denominator, and the code doesn't come out nearly as fast and isn't nearly as clever, but at least it is maintainable.

3) They can utterly fail to produce a quality product (I think this is the option usually chosen by default).

Personally, I vote for option 1, although option 2 is clearly what the industry shoots for, which usually ends up option 3 because option 2 is pretty hard to do right.

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

[mooingyak]

Almost invariably, unless the really good programmer puts an uncommonly high amount of effort into such things, the output of a single really good programmer will look like unmaintainable trash to most other programmers, especially mediocre ones, which are the norm in the industry.

We have very different definitions of what makes someone a very good programmer.

I know some programmers who have a decent amount of technical ability, but write such convoluted code that it's useless to others. This is worthless to me. They may as well not have coded anything, since it typically takes more time to figure out what's going on than it would to re-write from scratch. I don't consider such a person a good programmer, and I wouldn't hire any of them.

Paraphrasing Einstein, code should be as simple as possible, but not any simpler. Good programmers are ones who don't introduces unnecessary complications into code. Really good programmers are ones who can express something complicated very cleanly, or can lucidly document why they've done something strange.

Critizing people's code will make you look great!

[FriedTurkey]

Generally what is good code and what is bad code is all subjective. Yeah I know there are instances of really bad code but I see a lot of developer's criticize other's code simply because it is different. If it fulfills the requirements and can be maintained it is usually good code.

I also think people make a big scene to managers that the previous developer's code was bad simply to make themselves look good. The manager who usually doesn't code says to themselves "Well he must be a great coder if he thinks the previous developer didn't know what he/she was doing."

Another developer cliché is to complain about documentation. Doesn't matter if you write a war and peace size document to explian everything, the next developer is totally not going to read it. The next developer if he/she doesn't understand it simply says "This code is crap". This buys more time to become competent at programming changes and makes them look like a top coder to the credulous manager.