Technologies To Improve Group-Written Code?

iamdjsamba asks: "I've been working at my company as a programmer for about 4 months now, and it's apparent that the working methods could do with a refresh. Practices that we need to start changing are things like: non source-controlled changes that get uploaded to our website when they aren't ready; poor code commenting; and very little in the way of code reuse (if I write a class that could be useful to others, I have no easy way of telling everyone about it). I'm currently looking into ways to change this, and was wondering if anyone on Slashdot had experience of what's good and what's not?"

best practices

[StrawberryFrog]

It's a vague and non-specific question.

You've mentioned some of the practices that can help: have source control, have a build server attached to it.
Look into why this is a good idea: it automates ad-hoc, lengthy and painful build processes. Why are you getting "changes uploaded to our website when they aren't ready" ? make it so that going via the check-in and automated build is the best way to do this.

Look into code review methods.

Get some of your co-workers interested in best practices, and in being agents of change themselves. Are the problems apparent to them, or are they happy with the status quo? Can they get on your side here? Remember what the wise man (Martin Fowler) said: "if you can't change Your Organization, change Your Organization."

You don't say what tools you are working with, but in the .net world, tools like fxCop and nCover can be used, even integrated into the build process. The build can be set to break if the quality or coverage criteria aren't met. There may be such tools for your environment.

Re:Create simple rules

[Anonymous Coward]

7. Code reviews -- I can't tell you how many times I've caught typos or other problems in my own code as I've been explaining it to my code reviewer. I've also caught other coder's typos/problems when I've been a code reviewer. It also makes it less likely for one programmer to make a change in a dark corner somewhere and put it out there for the world to see without at least someone else's eyes having seen it first.

8. Design reviews -- if you're going to make a major change, after you've done some planning for the change but before you implement it, get other interested parties involved in reviewing your design. They may have other ideas for how to implement the change that may be better/simpler/less expensive/etc. than what you have planned, or they may have questions that will get you thinking about your own design in a new way. The design review process can be formal, in a meeting scheduled for the purpose of reviewing the design, or it can be informal, just you emailing the design to a few people and asking them what they think.