Without assholes, we'd all be full of shitPosted 2008-12-23.
It applies equally well to biology and to software development. It's easy to get everyone into a room to talk about coding standards and get everyone to agree that they are going to comment every public method, or that they are going to write good unit tests for every piece of code big enough to break. What's hard is getting people to follow through, and it's hard because it requires being an asshole. Nobody wants to be the asshole. Telling someone "hey, this code you just checked in is garbage, every method is public, and nothing has a comment or a unit test." Even worse is the status update with no basis in reality. How many times have you heard the following?
"What's the status on implementing component X?"
"Oh, that's great. Can I see it running?"
"Well, I haven't actually deployed it to staging yet."
"So you're just running it on local data on your machine?"
"Well, no, it doesn't actually work yet. But I think I know where the problem is."
Now, if you said that's a usage of the word "done" that you weren't familiar with, you might hurt someone's feelings. This kind of touchy-feely concern for feelings is counterproductive. While you might be sparing the feelings of the guy who doesn't want to come right out and say that he's behind schedule and drowning, allowing this kind of thing to happen frustrates the other developers.
I'm not arguing in favor of throwing around accusations and trying to assign blame rather than getting the job done. I'm talking about assigning meanings to words. Does marking a bug resolved mean that it's been deployed to production, that it's been tested in staging, or that it has been checked in but not tested? All of these are valid options. What's important is that the team agree on one (or if the team can't agree, that the team lead pick one), and that people are held to those standards. Without an asshole to hold people accountable, any decisions about standards or best practices are empty, any meetings are a complete waste of time.
Everyone wants everyone else to follow standards. Everyone wants all the code they have to take over and maintain to have good tests and clear APIs. But no one wants to go to the hassle of doing it in their own code. I don't need javadoc to remember what the method public int doItAndReturn() does. But the organization does. Realistically, I don't expect to maintain the code I write today. Sure, I'll work with it for a year or two, but chances are my code will be with the company long after I've moved on. At that point, if the code is unmaintainable, the business value suffers. Coding standards, test coverage, good documentation, and automation reduce the technical debt, but these standards don't happen by magic. No project manager will ever ask for refactorings. No manager will say "I see we have 90% test coverage, but are they good tests?" Standards need to be enforced by people who are in a position to see problems.