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

You don't ship test code

[BadAnalogyGuy]

One thing that really needs to be understood by all you "best practice" guys is that test code is not a shippable product. Requiring that all checkins be accompanied by unit test code is ridiculous because two developers working on the same code will need to update not only the code itself but also any test cases that rely on the behavior of the executing code. And if code A is supported by test code X, Y, Z, are you also going to require that any changes to A also be accompanied by changes to X, Y, Z? What happens if A is some fundamental architectural change (or maybe simply a refactoring) that affects all tests in the test suite? You can't seriously be talking about forcing the developer to go through the entire test suite looking for compilation errors and runtime errors just because those early tests don't make sense anymore with the new code.

You need developer buy-in to make a largescale standards effort work. You can do that by culling those developers who are realistic about development practices and by augmenting the remaining programmers with new hires who are just as standards-oriented as you are. Other than that, you'll be facing an uphill battle that will come to its conclusion the first time you approach a project milestone that is significantly behind schedule.

Do yourself a favor and get some test developers and testers. Let them worry about the test suite and let your developers worry about the product.

Re:You don't ship test code

[Osty]

One thing that really needs to be understood by all you "best practice" guys is that test code is not a shippable product.

Code without tests is not shippable code!

And if code A is supported by test code X, Y, Z, are you also going to require that any changes to A also be accompanied by changes to X, Y, Z? What happens if A is some fundamental architectural change (or maybe simply a refactoring) that affects all tests in the test suite? You can't seriously be talking about forcing the developer to go through the entire test suite looking for compilation errors and runtime errors just because those early tests don't make sense anymore with the new code.

You can, and you should. If your build is not organized enough that each developer can do a full build (or at least a build of modified components) prior to checkin then you have some work to do. As for architectural changes and refactorings, think of this as a small barrier to entry. It prevents frivalous re-architecting when your developers should be getting on with their real work. If a new architecture or a refactoring is important enough, then it's also important enough to fix or deprecate the test suite.

Do yourself a favor and get some test developers and testers. Let them worry about the test suite and let your developers worry about the product.

I agree with the idea, but not the sentiment. Testers and test developers are there ensure QA. They have their own job to do, and it's not mopping up after lazy developers who can't be bothered that they broke a build or checked in non-functional code because they didn't unit test. Bear in mind that the advocated "developer testing" really is minimum-bar stuff -- does your code work for the mainline scenarios? Maybe you have an obscure boundary condition or off-by-one error that you missed, and that's okay. What's not okay is just checking in a bunch of code and throwing it over the wall to the test department. Your quality will suffer and your testers will hate you. An adversarial test-dev relationship benefits nobody.

Re:You don't ship test code

[BadAnalogyGuy]

How fast does your codebase evolve? My money is on a glacial changerate.

As for "dumping" messes on others, I find it laughable that anyone would think that a developer whose mind is so geared towards developing a certain section of code would be able to objectively analyze and test their own code, much less write a test suite to cover the new code effectively. This is the same as asking an author to edit his own book. Sure, he may find the occasional misspelling or figure a better way to reword a chapter, but on the whole the work of editing is best left to editors.

The work of testing is best left to testers. An intermediate 'clear box' test team focused on the development and maintenance of unit tests is far more effective than the traditional dev/test organization that is so prevalent. By getting the development of tough tests out of the hands of the code creators, the tests are more likely to be fiercely objective and less prone to leniency.

As for creating a feedback loop, a developer who consistently puts out good code will consistently pass the unit tests and get to work on new code, but one that consistently puts out bad code will forever be stuck in the code-fix-code-fix cycle. If you were to leave the developers to their own devices, the first one would spend an inordinate amount of time writing good unit tests while the second one would write a test that was designed to pass. Or you'd have both writing the bare minimum unit tests which is worse than useless because you'd come to the incorrect assumption that the test was reaching some level of minimum quality when in reality the code is no less buggy than usual.

I don't doubt that unit tests are a good idea. I question whether it is a good idea to have the developers themselves write them, and whether it is a good idea to force the development of tests as a prerequisite to checking in code. Both sound great on paper, but reality shows that unless management is ready to step on the necks of the development team, that the practices get thrown out the window when projects hit the death march stage.

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". :-/