Ask Slashdot: How To Convince a Team To Write Good Code?

An anonymous reader writes "I am part of engineering team that maintains a very important component in our company. Our code quality and general engineering quality focus has been very weak: we have frequent buggy releases, our latencies are shooting up, our test coverage is nearly non-existent, and it is impossible for a newcomer in our team to get up to speed and be productive in less than a month due to unnecessary complexity. A group of 2-3 of us want to change that, and we know what needs to change technically — the better code review and release processes, better build tools, etc. But despite that, the quality of our code and design continues to suffer, and poor code continues to get released in the name of keeping the scheduled release date (product guys don't like to wait). We feel that if the right thing is done every time, we would can eliminate our issues and still release at the same pace. How do we effect the social change necessary to convince them of what is better and encourage them to take the effort to do it?"

Start small and do it in stages.

[ralphbecket]

(1) Code reviews. At first, just get 'em to grab a passer by to look at their code prior to check-in. If the PB cannot understand what they've done, they haven't finished the job. Later on you can upgrade to more stringent reviews, but the first thing is to get *some* reviews happening *at all*.

(2) Comments and (some) documentation. You need to lead by example. This stuff isn't optional.

(3) Unit testing. If your code base is a pig, you'll need to start somewhere and begin teasing out the "bits that think" (easier to UT) from the "bits that talk to things" (these are harder to UT and you can get away with integration testing here until you're in better shape). Unit testing is a skill anyone can learn. Sack 'em if they refuse to do it!

(4) Simplify your processes and your architecture where possible. Avoid trendy bandwagons. If the obvious thing works and is maintainable, then that is probably the best way to go.

Re:Sooo..

[invid]

I used to work for a company that produced avionics software. Obviously, we had to write solid code. This is how we did it: (1) Mandatory line by line code review by a different department. (2) Have a test cycle about as long as the development cycle. (3) Be willing to sacrifice the schedule to make it work. This is why planes are late and over-budget, but I wouldn't fly otherwise. And no, I had nothing to do with the 787.

Re:Sooo..

[Big Hairy Ian]

There are a number of things you could try.

1. Pair programming usually improves coding standards

2. Code Reviews can promote improved standards

3. Don't let them maintain code they've worked on before unless it's been round the rest of the team

HTH