To win people over to good development practices, projects must be run such that when people make major development practice errors, they will as soon and as clearly as possible see the *negative results* of their mistakes. And so that when people get things right, they will as soon as possible see the good effects *on the project* of getting things right.

A good test department could help with this, by sending developers prompt evidence that their crappy development style is preventing the developers from properly debugging their code.

Or people could be expected to give copies of their code to peer developers for review, and watch as their peer developers say "WTF? Your documentation is not clear to me at all, and your code design makes your code nearly impossible to document because it's such a mess." Hopefully the peer developers won't get caught in a "yes the emperor's new clothes are beautiful indeed" type effect. Or an "I'll praise your crappy code if you praise my crappy code" effect, in which case the problem is not so much that you need to promote better development style as that your coworkers are crapheads :-), or just don't know any better (yet).

BUT if it's impossible to show the developers the problems their bad development style is causing, maybe it's not bad development style. :-)

For example, some people think that "defensive programming" means writing your code so that when things start to get messed up inside your program's/library's/module's running state, the code tries to cover the problems up for as long as possible. This is bad for debugging. You want to know about bugs in your program as early as possible. If people think "covering up bugs until too late" is what "defensive programming" means, you will never win them over to it, or you will be sorry if you do win them over. :-/

Last but not least, you might say, "Gee, I hate when I have a humongous big pile of code and I have to debug all of it at once. That's really a big hassle. I like to make a little piece of code that's easy to test, and gradually work up, so that I don't ever have to put up with a humongous ball of mystery bugs, i.e. MONDO CRAPPO."

Then the developers (yourself included, you might not know as much about the best way to develop as you think you do) can learn from their own mistakes early and often!

The trick is not to say "RESPECT MAH AUTHORITY! FOLLOW MAH COMMANDMENTS AND ABSOLUTELY BELIEVE ANYTHING I SAY!" but rather to set things up so that people see for themselves what are better vs.worse practices. Even if they might discover that the books you are reading are partly wrong. :-)

Chris in Tucson, Iconoclast (Why not join tucson.pm? Oh, you're probably not IN Tucson, nevermind.)