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

Re:My answer, based on my experiences

[cmowire]

Ahh, but there is one real piece of evidence.

Always curly-bracketing your if statements will result in fewer bugs, statistically.

Why? Take this piece of code:

if (cond)
doThis()

now what's your first urge when you want to add something?

if (cond)
doThis()
doThat()

Works in Python and Ruby fine, but not in C. Hence always do things of the form

if (cond) {
doThis()
}

Re:Define good code

[dubl-u]

Good code, in no particular order:

I agree with all of these. A couple of notes:

Reuses, and is reusable, where sensible

Yes, especially that last part. A lot of developers talk about reusability, when what they're really doing is gold-plating, adding unused library features.

Is documented (Javadoc stylee, for preference!)

Maybe. I used to write a lot of documentation, but since I've started doing test-first development, I don't really much of it anymore. Why? Because A) I have a good suite of unit tests that document the functionality in a way that can be automatically verified, and B) doing good unit tests encourages you to break things down into small, testable chunks, which are easier to understand.