Improving Code Quality : LUSENET : Joel on Software : One Thread

A programmer in my team has a problem with buggy code. He has been programming for about 4-5 years, 2 years with our company. He is fast at picking up new skills - when he joined us he knew basic VB, he quickly learned ASP, IDL, COM and JavaScript. He is good at SQL and can write complex select statements. However he does write buggy code and it just seems to take ages going back and forward between testing and development to shake the bugs out. I gave him "Code Complete" to read and he says he has tried to put the principles into practise. He does all the tests he can think of when he writes code, but either the testers (or worse a customer) seem to quickly find something he didn't think of. Any ideas on what we should do?

-- Anonymous, July 25, 2001


How about code reviews for everyone? That way he gets to see examples of 'good' code from other people, other people get to see his code before the testers get into it, and the same benefits apply to everyone else too. While it may slow down the development phase of projects, it should hopefully speed up testing and reduce time spent dealing with customer problems.

-- Anonymous, July 25, 2001

Take a look at extreme programming, or try it out for a little while. Specifically, there are a few practices that might make this problem turn into an advantage:

-> Pair Programming Pair up programmers, and have them sit at the same terminal together. As your buggy programmer writes code, another programmer sits there and points out ideas in design and thinks of possible tests that will fail. When they're working together, they have no choice but to learn from each other, and the buggy programmer might pick up on things to do to increase code quality. More eyes actually looking at the code means less bugs in the final product.

-> Unit Testing/Test First Have the programmer anticipate tests that could fail, and code them before writing the program code. Your only goal is to get the tests to pass. Have a suite of small unit tests, and make sure they run every time you compile the program. A failure can quickly be recovered from, and you're never uncertain as to whether a piece of code works or not.

-> Simple Design How many bugs can you have if you keep it simple and modular?

Obviously, you might not want to do all these things, but trying them for a little while might not hurt. Plenty of books are available on the topic, so perhaps that's a good place to start.

-- Anonymous, July 26, 2001

A few suggestions:

1) Tell him to SLOW DOWN when coding; perhaps he's just writing code too quickly. Have him flowchart each function on paper first, even if it's on scratch paper, to help him think out the task better.

2) Transfer him to QA for a while to help him see code and code defects from a different point of view.

3) Have him focus on one or two languages, not 6, and learn them well.

4) The last possibility is that he simply isn't any good at programming. Just because a person can write code doesn't mean that they're a competent programmer.

-- Anonymous, July 27, 2001

Send Him Back to School

I'd be impressed if he could write *simple* SQL statements, not complex ones. Are you in the training business or the software development business anyway? Don't get sucked into the role of the guy who can help everyone. They're usually the first to drown.

-- Anonymous, August 24, 2001

Moderation questions? read the FAQ