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.

Machiavelli

[Harmonious Botch]

Machiavelli said something to the effect that the prince should dole out the sweets in small ammounts on a regular basis but put all the bad news in one package and get it over quickly. ( Sorry. I don't have the time to look up the exact quote )

People are creatures of habit. They don't like changes. Every change that you make in their working environment is a small negative experience to them. Even if it is something that they might agree is a good thing, it is still a change, and thus a negative thing to them.
This, unfortunately, conflicts with the desires of a good manager, who wants to make improvements in his business every day. Even if they are GOOD changes, making changes every day is a sure way to alienate your employees.

So, be patient. Only make frequent changes if an emergency requires it. Otherwise, make a list of planned improvements, and keep it to yourself. Add to it weekly, or even daily. Then, once or twice a year, implement it all at once.
It sounds contradictory, but people will adjust to a bunch of changes better than a few, IF they know that the rest of the time their work will be relatively consistent. You can ask them to be in an absorb-the-changes mode once in a while, but not all the time.

Change Adoption

[KDan]

One of the most effective techniques I've used to encourage adoption of change is to get the people who will need to change to own the new process. How do you do that? You heavily involve them in designing the process, expose them to the reasons why the process is good, get them engaged in discussions about how to resolve the problems that you're trying to resolve. Sure, you're bright and everything and you know the solution already, but that doesn't mean everyone will do as you say.

Best way to do this is for you to create an imperfect solution then have one-on-ones with all the key stakeholders and get them to contribute to it. Expose them to the business requirements (expose them to the business if need be) so that they understand perfectly well why this is happening, and get them to own this process and thus commit to it. Then once everyone's agreed that this is the way to go, you can set up some sort of regular measurements to track the adoption of the processes. Make those measurements visible and the key stakeholders will get these processes adopted by their teams.

Daniel

Test-driven development

[Anonymous Brave Guy]

Let me be clear from the start that I have nothing against automated testing, nor against unit testing at a low level, nor against combining these two ideas.

However, I think it's important not to place inappropriate faith in them. I have heard senior programmers recite the mantra that you can refactor your code as much as you like, because as long as it still passes the unit tests, you know you didn't break anything. I look at those people and wonder how they got to those senior positions. Do they really believe that you can ever have an exhaustive set of unit tests, no matter what the context? I have seen cases where rewriting a pretty trivial arithmetic expression in a tidier form worked fine on one machine, but completely broke the optimiser with a different compiler on a different OS, resulting in a subtle change in numerical outputs.

IME the hard-core TDD advocates also have a false sense of security when it comes to design. Just because you have some tests in place, that does not mean you can design on-the-fly all the time, and suffer no overheads. There is a reason that good software engineers spend a lot of time designing and not much time writing code: it's because writing the code (and getting it right) is much easier with a clean architecture that's designed to be flexible and maintainable. Of course you can't plan everything up-front, but the whole "anything's OK as long as it passes our unit tests" approach is a recipe for endless headaches when your design starts to evolve, and can lead to weeks or months of wasted time later when a new feature can't just fit into the existing code because there's simply nowhere to fit it.

Re:You don't ship test code

[Stradivarius]

I would suggest that the original developer is the best person to develop the tests, because thinking about how you're going to test your code often exposes flaws in your design, interface, or implementation. Better for the developer to realize that early in his process, than after the fact when some QA or "test developer" comes along and says something doesn't work quite right. It's almost always faster/cheaper/more efficient to fix a problem early on in the lifecycle than at the end.

Besides, the developer is typically going to do *some* sort of unit testing to convince himself that his code works. It's often not a huge effort to formalize that already-planned testing into a repeatable/automated unit test.

You're right that there is the rose-tinted glasses effect, but you can overcome that by including unit test code as part of peer review that happens on the "regular" code. (This obviously assumes the company does some form of peer review; if they don't then who is picked to write unit tests is the least of their problems).