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

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.