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

[kfg]

This Ask Slashdot question just cries out for its companion question:

How do you get management not to implement a new standard or 'best practice.'

KFG

Re:You don't ship test code

[BadAnalogyGuy]

Lots of "clean up our practice" Ask Slashdots lately.

Here's another one that seemed a little bit hopeless: http://ask.slashdot.org/article.pl?sid=06/11/10/04 1257

I have a feeling that as word gets out that Microsoft is getting deep into the whole Agile phenomenon and using it as much as possible throughout its teams, that other companies want to emulate the dynamicism for themselves. However, what works for one company (especially one focused on building consumer applications) may not be a realistic or useful methodology for another company (like one trying to implement a system based on pre-packaged components).

That's not to say that Agile or XP or DP or Booch or Rumbaugh or Rational or Waterfall or any of the myriad development methodologies aren't useful. They are imminently useful *within their useful domains*. Once you start trying to apply a square methodology to a round development team, you're bound to run into problems. If you are deadset on implementing a set of standards, make sure you understand the methodology completely first, otherwise you'll end up with a half-assed implementation of piecemeal tactics without a comprehensive strategy.

Just look at Iraq for an onerous example of a project with capable team members and highly effective tactics led by incompetent managers with no overall strategy. You don't want to build that sort of company.

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.

Re:You don't ship test code

[Coryoth]

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.

The solution to that, of course, is to integrate test definitions into the code itself so that it all gets updated together. As a bonus your API documentation is more precise and gets updated along with the tests and the code. You can then push a button, walk away, and have an automated testing system fully exercise your code. And yes you can have all of that for Java if Eiffel isn't to your taste (though it might be worth having a second look at Eiffel).

In other words, yes if you want software with lower defect rates you should expect developers to update their specification (and documentation) of how they intend code to be used and to work at the same time that they update the actual code. If you want to specify working code by having it pass a separately written unit test, fine; but that's not the only way, nor is it always the most efficient.

What I'd Do

[hahafaha]

> 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?

Adopt the new practicer. Or you're fired.

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.

Maybe involve them?

[seebs]

One thing that might help would be to involve them in the decision-making process. A lot of the "best practices" I've seen handed down were monumentally stupid ivory-tower junk.