Slashdot Mirror
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."
Code without tests is not shippable code!
Right on. However should the ultimate goal of a project be to develop a great test suite? Maybe so, if your product is the test suite.
Tests are necessary and automated tests are spiffy and should be part of any comprehensive testing effort. Having the developers create them themselves seems to be a waste of time. My other post to the AC whose code is flawless addresses this issue.
If your build is not organized enough that each developer can do a...build of modified components...prior to checkin then you have some work to do.
Amen. However compiling code is hardly the same thing as writing a test case. Clean builds should absolutely be a prerequisite to code checkin, no question. However, is that same sort of rigor necessary for behavior tests? Most developers don't code up something, build it, then toss it over the wall. At a minimum, the developer will typically put the new code through a few paces before sending it to test, so there is definitely some testing going on at the development level. Is more than that needed? Yes, sez you and many Agile enthusiasts. Personally, I don't see it.
I see a lot of time and effort going in to writing tests that will pass the new code, not tests that will fail it. Developers have a funny faculty of seeing their code through rose-tinted glasses, and their unit tests reflect that. Just because you have 100% of the codepaths covered by the unit tests doesn't mean that anything except for program flow through those codepaths is tested.
Testers and test developers are there ensure QA.
Yes, absolutely. This is why I think that there ought to be another team attached to the developers who have full access to the code whose responsibility it is to develop and maintain the unit tests. When a checkin breaks the unit tests, the developer responsible must either address the problem as a bug (ideally, the unit test team would be working from interface specs, but should be adaptable) or the unit test developer must update the test suite to accomodate the new feature.
IMO, the test team should be made up of people who are capable of programming, so that they are empowered to be test developers (SDETs) themselves. Too many times I've worked with test teams made up of people who took a community college Intro To Computers class and sat around all day pressing buttons and writing down results for tests created by the SDETs. What a waste! If you need button pushers, hire them as temporary contract workers, but get your core test team to be proactive in creating a solid test framework that can be automated as much as possible so that they don't themselves end up sitting around pushing buttons.
lazy developers who can't be bothered that they broke a build or checked in non-functional code because they didn't unit test.
Broken builds happen way too often to say 'It should never happen', but it should never happen. I'm surprised that uncompilable code could possibly enter the codebase, but I suppose those sorts of developers exist too. Weed them out of your company as soon as you can, is my only advice in that case. The occasional 'checked in all files but one' type of build break is bound to happen, though good source management tools can help alleviate this issue.
A good compiler with warnings or a tool like lint can make dead code easy to spot. If your strategy includes a restriction that all code must be warning-free, that's a very minimal requirement and one that is easily adapted to. If you say instead, "unit test all codepaths," then your developer is suddenly facing not only the bugfix of the original bad code (which would have been found by lint) but also the development of new code whose sole purpose is to exercise the bad code. It's a waste of effort and the developer will try to get away with the minimum amount of effort possible, which leaves you with the illusion of tested code but the reality of bad code + bad test code.
Bear in mind t