Getting Development Group To Adopt New Practices?

maiden_taiwan asks: "At my software company, we occasionally need all engineers to adopt a new standard or 'best practice.' Some are small, like the use of Camel Case for function names, while others have tangible business value, such as 'every check-in must be accompanied by a unit test.' As you might guess, some new practices get ignored, not because people are evil or lazy, but because they're simply too busy to pay attention and change their work habits. So we are seeking creative ways to announce, roll out, and enforce a standard for 100+ engineers so they will actually follow it." What ways have you used to convince your developers and engineers to adopt a new set of practices that may or may not get in the way of their daily work habits? We already know to automate compliance when possible (e.g., the revision control system could reject check-ins without unit tests), and simple platitudes like 'tie compliance to their year-end bonuses' aren't helpful by themselves, as someone will still need to check compliance. The engineers here are smart people, so we want to spend less time on enforcement (having architects read the code and flag any non-standard practices) and more on evangelization (getting engineers to see the benefits of the standards and -want- to follow them). I'd welcome any advice on formal processes or just plain fun ways to get people's attention."

Comments

Beat 'em over the head

[AKAImBatman]

At one of the jobs I worked at, we had a fellow who's sole role was to maintain the Version Control system, and manage the releases directly from that system. He was incredibly good at his job, to the point of politely beating the matter out of programmers who didn't comply. So if you just happened to forget to tag something for release (or otherwise tagged something that shouldn't have gone), he'd be over to let you know that you broke the build AND (here's the important part) work with you to get it resolved.

Honestly, having the guy around was the best thing that ever happened to our code tree. Suddenly, we developers didn't have to worry about handling all the minutia related to a test or production build, we didn't have to worry about pruning the tree, and we knew someone was watching our backs in case we screwed up. I know that my description probably sounds horrible, but it was honestly great! The whole process got a lot smoother after he came on board.

I think the key reason why it worked was because most developers wanted to follow good version control procedures; they just didn't have the spare bandwidth to manage it. By centralizing the handling, it offloaded a great deal of that duty and made everyone's lives easier. It also made clear the people who were intentionally keeping source control a few versions behind for "job security". :-/

Performance tracking with bonuses

[KU_Fletch]

At my software company, we have yearly bonuses and profit sharing. Both can be affected by what we call a "quality factor" or as some of our programmers deride it "quantitative quality." Basically, we have some set in stone rules set by our leads when it comes to workflow issues. For example, software compiles are scheduled every night at 8 (and a second at midnight if needed). Your work needs to be checked in to our tracking software by 8. If not, the compile will break. If you break a compile, your quality factor score goes down. If you remember and check your work back in by the midnight backup compile, your score ticks back up slightly. There are about a dozen of these rules, and they all center around interrupting other people's workflow. If you screw up a nightly compile, it means when people come to work in the morning, a new compile has to be kicked off and everybody has to wait. Every person whose workflow is interrupted gets a share of your quality factor points you lost. So at the end of the year, if you never screwed up, you get more money in your bonus. If you were constantly screwing up and making other people lose productivity, then you get less money and they get more to make up for your screw ups. If you screw up a normally expected amount of times, it ends up in a wash.

Before you ask, yes, there are certain people that hate that rule. But those people tend to be the ones losing out on money, and the ones screwing up a lot. Screwing up once or twice is no big deal. Screwing up on a weekly basis hurts you in the long urn, but it's really their fault for not correcting their problem. No, the entire bonus and profit sharing is not based around it, but it is a good chunk. One guy I shared an office with last year lost nearly $2000 out of his bonus. That ended up giving everybody about $50-75 more. Sure, that's not much of a gain for certain people, but it's a nice chunk of money to treat your wife/girlfriend to a nice holiday dinner at the end of the year. The important part is the loss hurts you big and requires that you stick to good practices for a long time to make it up.