Making the case for code quality

Question

Imagine you're working with developers who habitually write 300 line nested methods full of errors, possible errors, etc. etc. Applications regularly throw exceptions as a matter of course, and much time is spend hunting odd intermittent bugs.

How do you go about making the case for better code and better standards? How do you make the case to developers who are used to coding in a particular style (badly) and don't see the need or benefits of change?

I suppose as a side question, what's been your experience with working with people in this kind of a situation, and what have you done that's worked positively?

A clarification - Thinking mostly in a situation where a number of positive things have been suggested. The question is not so much "what would work positively?" but "how do you get someone else (who's not terribly receptive, because, after all, what they've been doing habitually seems to work fine) to see the value of taking any of these positive steps?"

Answer 1

Try adopting some XP practices. You might wanna start with pair programming/reviews and automated unit testing.

Answer 2

I recommend pairing a validation engineer with a programmer to work together to validate the code prior to use.

I would recommend adopting coding standards within your group.

Finally, I also recommend some type of Code Inspections (much more rigorous than code reviews).

Answer 3

Unless you are in charge, you cannot force change. All you can do is model the good behavior and by the improved quality show the benefits, both to your peers and to your bosses. If you can then get the buy in from above it becomes much easier.

Answer 4

People are always reluctant to change, especially when it seems like it might be more work. To that end, you really need the support of a project's technical need so that some quality assurance is mandated, such as:

• Clearly documented coding style for the project to follow
• Step-by-step design-to-release process (i.e. reviews and checks that are made at each step from designing the work through implementation to release into the code surface)

For .NET code, tools like FxCop and StyleCop are invaluable in helping to enforce and justify coding standards. I am sure there are other tools available for non-.NET code that can inspect code and enforce style.

Peer reviews are also well worth the effort as they not only help to improve code quality, but they contribute to knowledge sharing.

Answer 5

It takes a strong lead whom they respect for his/her technical experience to impose some standards, since the code is owned by the team.

If there is no shared code ownership, implement code review, bug-tracking and root cause analysis and have a leaderboard for people with fewest bugs traced to their code. They should want to learn the techniques which are more effective.

Ultimately, those people need to be off the team if they don't change, see the need to change, or understand the benefit of change. Again, it takes a good lead to get that across, and developers who will be team players.

Note: If the developers are smart and the standards are silly, they will not respect them. If the developers are smart, though, you would have thought they'd have figured this out for themselves, but you never know how some people got where they are.

Answer 6

Some people naturally have a cluttered mind, and it shows in their code. Some times it boils down to a developers personal plilosphophy and they don't care to think ahead, or write nicely organized code. And sometimes they just don't know any better.

Are these senior developers, or junion programmers? The answer might determine your success level when trying to change their coding style.

Try Write a coding style document, detailing suggested techniques, particullarly around issues you typically see in the code you see on a daily basis. This might be better than simply trying to adopt an existing document already published, which may be large and deter people from actually reading it.

Try finding poorly writtin code, re-write it, and hold a short weekly meeting to go over the changes, so you have a chance to explain how the changes benefit the application.

One thing I've noticed is that a lot of developers sit all day staring at their monitors writing code, where if they got up, took a short walk and pondered what they were doing before they wrote the actually code, they might realize a benefit. I know I do.

Answer 7

With people in this position addressing the subject head on will never work - you'll just end up with a world of antagonism.

Instead try and sow the seeds obliquely - enthuse about 'Code Complete' - buy whoever shows the most interest a copy. Get them on your side and work outwards from there.

Answer 8

make them responsible; if they share your pain then they might be motivated to make it go away. For example, trap all unhandled exceptions and notify the developers when they occur. Get a report every day of the exceptions in all the apps and chart whether they're recurring or not...

<blatant self-promotion>

You could use CALM and make notifications go to the developers that created the applications. If email isn't painful enough, give them pagers and redirect notifications to the pagers 24/7.

</blatant self-promition>

when they start whining about 100 emails in their inbox or getting paged in the middle of the night, then maybe they'll be motiviated to change the habits they have that cause the problems...

EDIT: if you're not in charge of the team, sell the manager on the idea, or let him/her think of it [with gentle prompting of course].

Answer 9

"developers who habitually write 300 line nested methods full of errors"

It isn't habitual. It's cultural. Someone is reinforcing this behavior. Somehow early delivery of stuff that compiles but doesn't really work is rewarded.

Your job is to find the positive feedback loop that makes this situation rewarding for all concerned.

My experience is that some manager gives plaudits and kudos for "right now", and doesn't seem to know the difference between "right now" and "right". This is the kind of person that needs to see the cost of "right now" and the money saved by "right".

With constant positive feedback, they can slowly start to insist on unit tests that actually pass instead of constantly rewarding instant gratification. They'll backslide constantly, BTW; be prepared for lots of mixed signals and undermining and saying one thing but doing another.