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

[Anonymous Coward]

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

Yes, and yes. That's why our code has a negligible defect rate.

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

Unit tests are specific to the development team. Clean up your own mess you wrothless bastard, don't dump it on others.

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

[ClosedSource]

You took the words right out of my mouth. Management is always looking for the next silver bullet as long as schedules, costs, and contents don't have to be adjusted.

Of course, it's often one of your own "control-freak" team members that give management the idea in the first place.

Re:You don't ship test code

[Anonymous Coward]

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.

This is an awful analogy. An editor is more like a compiler or syntax checker. Computer code is not prose.

Re:You don't ship test code

[BadAnalogyGuy]

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

Re:You don't ship test code

[johntonsoup]

Having to regularly rewrite unit tests indicates poor design in the first place. Of course, if your company has very loose design rules, throw the unit tests out the window.

I've had good and bad experiences with QA people. It seems like the best QA people are also really good programmers and designers. They come along, see why you wrote the code the way you did, and think of good test cases that you may have forgotten.

Bad QA guys don't understand the language (boo, gui testers) and have no design experience. Usually bad QA people are found at companies that treat QA like second-class citizens. If your programmers are way out of the QA guys' league, QA isn't going to find many interesting issues (and I promise you, there are interesting issues to be found).

Re:You don't ship test code

[BadAnalogyGuy]

Computer code is not prose.

I'm not advocating this particular methodology, but there are people who would disagree with you.

http://www.literateprogramming.com/

Re:You don't ship test code

[mOdQuArK!]

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.

That's why the developer is supposed to write the unit test _before_ they write the code they are actually testing. That way they can be reasonably sure that the unit test doesn't depend on the implementation details of the new code, plus it provides a strong unambiguous target for the new code (must compile, run & make the unit test(s) pass before it can be checked in).

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.

Re:You don't ship test code

[BadAnalogyGuy]

This presupposes good specs and a well-designed architecture to begin with. If the Agile and XP methodologies are to be believed, specs change, architectures change, so rapid response capability is absolutely necessary to keep development well-paced. However, if specs cannot be trusted from the outset then how can they possibly be useful as the basis for unit tests? Your work to get those tests working will be wasted since you will end up reimplementing them as the specification morphs and solidifies.

I like the idea of having rapid response development (I hesitate to use the word 'agile') but I see Agile methodology, at least as commonly practiced, to be nothing more than the common Waterfall methodology with a stronger emphasis on up-front test development and shorter milestone cycles.

Maybe I haven't drank enough of their Kool-aid, but any methodology that prioritizes test development time above code development time assumes too much, IMO.

Re:You don't ship test code

[BadAnalogyGuy]

I think it's useful to separate runtime invariant checking from unit testing as concepts. The first, which is what Eiffel provides very well, should not be considered part of code verification. Rather, it should, IMO, be considered standard development practice. Verify what goes into your function, verify what comes out, verify that nothing is beyond acceptable boundaries. Assert on failure.

That is different from unit testing which seeks to build a wrapper around units of code in order to put the code through its paces. It can identify areas of code that are problematic, are never executed, are buggy, or generally are seemingly okay. Spending an inordinate amount of time writing these tests is hard to justify because it doesn't aid in debugging and must be itself correctly implemented.

Asking developers of code to write unit tests is a mistake, IMO. They should, however, be aware of invariants and have a judicious sprinkling of invariant checks throughout the code. When the test team finds a bug, the invariant checks may be useful to nail down the problem. Unit tests, while helpful to judge the quality of the code, are not helpful at all in debugging.

Re:You don't ship test code

[chromatic]

Having the developers create them themselves seems to be a waste of time.

In my experience, any developer worthy of the title "developer" already tests his code, though perhaps not in an automated fashion. I've seen plenty of developers (and I've done this myself) use debug statements to build up a function or method in pieces, checking the output manually each time.

Actual test-driven development (not after-the-fact writing a few half-hearted test cases) is a refinement of that process. It has three benefits. First, it captures those manual tests in a permanent format that I can run any time I want. Second, it gives immediate feedback as to the state of the code and allows me to work in much smaller increments of time. Third, it changes the way I approach code and low-level design. My code tends to be simpler and shorter and more cohesive and less coupled (and much, much easier to test) this way.

Having a poor developer create dozens of lousy tests does no one any good. However, my experience with doing TDD myself (and teaching other people how to do it and writing libraries to help them do it) makes me think that any decent developer who tries to do it seriously and with discipline will produce better code.

Re:You don't ship test code

[eyeye]

Dude, I have read a few comments of yours in this thread and it is clear that you don't really have any idea of the benefits of unit tests. Testing isn't something that should be done at the end with your fingers crossed. Defects cost more to fix the longer you wait to have them exposed.

Re:You don't ship test code

[BadAnalogyGuy]

I appreciate the sentiment, but am quite at a loss to argue since you haven't provided any examples of the benefits of unit tests.

Nor have I argued that unit tests are wholly useless. In fact, I've argued that projects without unit tests are usually in worse shape than projects with them.

Step up with some benefits that I'm not aware of and earn your +5 Informative, please.

Re:You don't ship test code

[Coryoth]

...unit testing which seeks to build a wrapper around units of code in order to put the code through its paces. It can identify areas of code that are problematic, are never executed, are buggy, or generally are seemingly okay.

If that's what you're using unit testing for then I agree, that's rather a waste of time. If you want to find areas of code that are problematic, never executed (unreachable) or buggy, then you're better off using a static model checker like ESC/Java2 or ES-Verify. Of course both of those require you to specify your code with contracts so they have something to verify against, but then as you say, you ought to be doing that anyway.

Of coure not everything can be completely adequately specified in contracts, and for that you will probably need unit tests, and acceptance tests, or variations thereon. However, as you point out elsewhere, that sort of testing is more the sot of thing that the testing department can handle. Maintaining code specifications as part of the code itself to allow for automated testing and model checking is something you can expect of developers however.

Re:You don't ship test code

[UPi]

The submitter didn't ask us to dictate his methodology for him. He asked for advice for how to enforce a methodology that he has already chosen. You're just not being helpful here.

The trouble with change is people with your attitude: if you refuse to understand the rationale behind certain practices, you will either ignore them, or comply at a bare minimum level at which they are not useful. My advice to maiden_taiwan: try to reason with people. Explain to them WHY you want them to do what you want them to do. Do this at as personal a level as possible, so they can ask questions.

Obviously, with 100+ people, there's going to be some who will be completely unwilling to listen or to compromise. You have to be prepared to let them go.

Re:You don't ship test code

[BadAnalogyGuy]

If that's what you're using unit testing for then I agree, that's rather a waste of time.

And that's the thing. Unit tests are not a waste of time when done correctly. However I have not seen good unit tests systematically developed and maintained for the life of any project. Either it ends up being when I described previously or thrown out altogether when the burden of writing the tests outweighs the need to hit a deadline. Despite their benefits, there is only a finite amount of time between kickoff and release party and when the deadline looms large and the managers are scrambling for things to cut out of the path of developers, unit testing is one of the first things to go.

Better, IMO, to get a separate team involved in the test development (not the test team) whose primary job is to verify new code with unit tests. That allows the developers and unit test team to develop in parallel, thus getting the benefits of unit tests without the drawbacks of doubling the workload of the developers. Given good initial specifications to which both subteams can develop towards and given good communication channels between the teams, I believe that it would be quicker to develop code with better quality than with the developer-developed unit tests.

Re:You don't ship test code

[BadAnalogyGuy]

You're just not being helpful here.

You sure?

try to reason with people. Explain to them WHY you want them to do what you want them to do. Do this at as personal a level as possible, so they can ask questions.

Obviously, with 100+ people, there's going to be some who will be completely unwilling to listen or to compromise. You have to be prepared to let them go.

And that's different from my advice?

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.

Re:You don't ship test code

[Osty]

Not if you're listening to Agile advocates. The leaders of that movement sometimes express the opinion that unit tests can eliminate the need for real testing. After all, you've effectively tested the code in all its codepaths. Testing is a mere formality, IOW. I don't buy that, and I don't think you do either.

I think this sums it all up. We're both advocating the same thing, that the "best" way to develop software is somewhere between extremely "agile" methodologies and walled-off teams. But it's a gradient, and I think I fall a little bit farther towards "agile" than you do. IMHO, "agile" methods should never be followed to the letter. Instead, you pick a little bit from column A, a little bit from column B, and so on. Unit testing is never a replacement for full QA, but working closely with testers (by which I mean test developers) is a good form of "pair programming" (real pair programming is crap). Stand-up meetings are all well and good, but I've found that you can have a sit-down status meeting with 4-7 people and still be done in 15 minutes as long as you have good leadership and avoid rat-holing. Short release cycles are great when you only have maintenance work to do, but there's nothing wrong with bundling two or three cycles together when you have a number of big features that need to be done. And so on.

Re:You don't ship test code

[Fulcrum of Evil]

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.

Spoken like someone who doesn't have to maintain old code.

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.

Who's the most qualified? The original dev. QA guys test overall system behavior. Devs are responsible for unit testing.

Re:You don't ship test code

[BadAnalogyGuy]

Most of my career has been spent maintaining old code. Much of that time has been spent fixing bugs in both the codebase and the unit tests. If my posts express an opinion, it is because I speak from my experience which may be different from yours.

The original dev, as I've already discussed is the least qualified to analyze his own code. And the sentence to which you are replying has to do with the quality of the test team rather than anything to do with development, mainline code, unit test code, or otherwise.

I encourage you to actually go back and read my posts because I don't think you've understood my points or my proposed methodology at all.

Re:You don't ship test code

[Anonymous Coward]

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

Zero to production in fifteen months for a decent mid-sized project. No sweat.

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

Well, if they're such crummy developers that they are truly unable to determine which lines of code that a given unit test exercises, there are these nifty new tools to do code coverage analysis for them.

>This is the same as asking an author to edit his own book.

No, this is the same as reminding the carpenter to "measure twice, cut once". Most developers doen't even bother to measure once; they just saw off a chunk by eye and ask somebody else if it's the right length.

>The work of testing is best left to testers.

For the love of God, UNIT TESTING HAS NOTHING TO DO WITH QA! Unit testing checks for correctness at the individual function or function group level. It is a check by the developer that what they wrote does what they think it does.

Even if the QA at most shops weren't little better than monkeys, wasting your best testers on tracking down simple "Oops, oh yeah I forgot that case" bugs instead of actually doing what they do best is an idiotic waste of money. Let the person who knows their code best (or one of his/her peers) double-check their own work.

Re:You don't ship test code

[Bastard of Subhumani]

An editor is more like a compiler or syntax checker.

Can a compiler understand a functional spec? Are the syntax errors the only errors in coding - which would imply that if code compiles, it's correct?

Your analogy is bad, unless it's a bad editor you're describing.

Re:You don't ship test code

[Bastard of Subhumani]

Let the person who knows their code best (or one of his/her peers) double-check their own work.

Sounds great in theory. The problem is that if a developer forgets to code a particular case he'll probably forget to test it. If he codes on the assumption that the spec means X, he'll test on that assumption.

Can't beat a fresh pair of eyes.

Re:You don't ship test code

[BadAnalogyGuy]

fifteen months for a decent mid-sized project.

I envy your team. You have a great PM who is able to pad a schedule quite ably. (Seriously, over a year? Where do you work?)

if they're such crummy developers that they are truly unable to determine which lines of code that a given unit test exercises, there are these nifty new tools to do code coverage analysis for them.

The point was that developers have a different view of their code than objective outsiders. They will not create as good of tests as someone not intimately associated with the code.

No, this is the same as reminding the carpenter to "measure twice, cut once". Most developers doen't even bother to measure once; they just saw off a chunk by eye and ask somebody else if it's the right length.

I don't think you'll find anyone is arguing that developers should be cowboys and just spit out code all day long. I'm certainly not advocating such a stupid thing.

What I am saying is that development time is finite and asking the developers to write unit tests is a waste of time since 1) it takes up actual time and 2) they have a vested interest in successful unit tests.

UNIT TESTING HAS NOTHING TO DO WITH QA

And if you had read past the first sentence you would have understood that I am not saying that QA should be writing unit tests but that the development team should have its own set of unit test developers who work in parallel with the code developers towards the goals of the specification. QA (the separate testing team) has nothing to do with what I am talking about.

Even if the QA at most shops weren't little better than monkeys, wasting your best testers on tracking down simple "Oops, oh yeah I forgot that case" bugs instead of actually doing what they do best is an idiotic waste of money

I am very disappointed to see this attitude. While I do agree that many QA departments are staffed badly with people who are ill-qualified, I find the attitude that they are "little better than monkeys" atrociously condescending. It is the persistence of this attitude that drives a wedge between dev and QA and makes many QA engineers view development as a step up rather than a step sideways. Some of the best engineers I have ever worked with have been QA engineers.

Unit testing code is similar enough to testing that repurposing a handful of development-oriented QA engineers for unit test development would allow extra breathing room for the code developers and the increased code quality would see to it that the QA cycle went smoothly. Are you going to argue that better unit tests are going to be worse for the product cycle?

Let the person who knows their code best (or one of his/her peers) double-check their own work.

I am in agreement about code reviews and informal walkthroughs before checkin. When done well, they have been more effective than any other development technique at sniffing out coding mistakes in my experience.

I do not agree that the person who wrote the code is the best person to judge the fitness of their own code, even if they take serious pains to double check their work well. It is because they have the code fresh in their mind that they cannot see the mistakes. It is because their ego is intimately tied to the code that they look for success rather than failure. An objective outsider (whether it be a peer developer or someone else) will be far more qualified to judge the fitness of the code than the coder himself.

We aren't talking about sawing pieces of wood. We're talking about the design and implementation of complicated machines that require intense focus and attention to detail. It forces the developers into a certain pattern of thinking, potentially blinding him to his own errors, and the difficulty and rewards of success bind the programmer's ego to the code such that he cannot judge its fitness objectively.

Re:You don't ship test code

[Bloke down the pub]

Yes, it is different. He appears to recommend getting rid of the ones who aren't realistic about development practices - which seems a lot more sensible to me.

Re:You don't ship test code

[CxDoo]

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.

I didn't get this; you are suggesting to get rid of realistic people in order to introduce standards-compliant practices?

Re:You don't ship test code

[BadAnalogyGuy]

That's what I'm saying. You need to understand what I mean by 'realistic' though.

A realistic developer is aware that most methodologies have good points and bad points.
An unrealistic developer thinks that the hot methodology of the week is the silver bullet.

A realistic developer already has a toolkit that serves him well.
An unrealistic developer has an overflowing toolkit with many deprecated technologies.

A realistic developer knows that once the fervor over the methodology of the week that tried and true strategies will still be the core of the development cycle.
An unrealistic developer thinks that the methodology of the week is here to stay.

A realistic developer sees the effort to push strict standards as folly.
An unrealistic developer can't wait to follow all the rules to the letter.

A realistic developer, when the methodology of the week fades away, will take from it what is useful.
An unrealistic developer seeks the next methodology of the week.

A realistic developer recognizes when management starts making weird rules and starts looking outside the company.
An unrealistic developer trusts the company and believes that it has his best interests at heart.

So yes, a realistic developer will typically be resistant to change and will be a bad influence on the rest of the developers if you can't get his buy-in. It is better to get rid of those guys first so as to make the transition easier with the wide-eyed greenhorns than to let them undermine your efforts by keeping them around.

This is not to say that unrealistic developers are bad developers. Many times they are very good at programming, just naive about company politics. Sometimes it's better to have a company full of these believers than a company full of grumps.

Re:You don't ship test code

[CxDoo]

I supposed your thinking went along these lines, just wanted to make sure before I comment on it.

First, since you're trying to establish a tradeoff between obedience and competence, you should have stressed "if you can't get his buy-in" part - getting rid of people just for being realistic is, simply, wrong.

Second, giving priority to method (or process, or standards compliance or whatever) over creativity, being realistic (or however you call it) is not the best solution for every case. It is if your process is optimal, i.e. everything is perfect in your environment and you just need to replace an odd wheel here or there, but if you are in the process of establishing a process, getting rid of competent people who might object and replacing them with yes-men (or clueless enthusiasts) will leave you with a formal shell around nothing. You'll simply have no *real* feedback on where your system is going.

Re:You don't ship test code

[Anonymous Coward]

TDD only makes sense to be done by the original devs.

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).

Re:You don't ship test code

[ThePiMan2003]

The entire point of this argument though is that any competent developer already checks for all of the cases they can think of, so any unit test they write will automatically pass their code. You need someone with fresh ideas to write a test that actually has a chance of failing. On the other hand if you have incompetent programmers who write unit tests they know will fail because they didn't check for one series of events... why would they not fix the code before writing the test? Meaning that once again the only thing the unit tests will detect are things they have already anticipated.

The benefit I have found for unit tests is defensive programming. If I write a test that proves my code works, and some other person breaks it so my test doesn't pass then its not my fault. But, that sort of thinking leads to serious friction inside your department.

Re:You don't ship test code

[Anonymous Coward]

Enforcing that tests are written before the implementation is done in the (not always unfounded) hopes that this practice encourages a mindset where developers ask themselves "What is it I want to achieve, what is my valid input range, and what is my valid output range?" before starting to code. It's design by contract in the mind. Unfortunately, that sort of thing does not happen often enough.

Agile methodologies unfortunately encourage an opposing mindset, where coding and the design process interweave more strongly. Of course you can't write unit tests in advance if you have no design in mind. The pitfall here is that agile methodologies sound suspiciously like a very intuitive approach to coding and design, where you make up the design as you go along. That, in my experience, invariably leads to bad code quality.

When agile methodologies propose writing unit tests before implementation, what they implicitly assume is that developers understand the distinction between short design/code cycles and the mixed up intuitive approach to design. That's not something that is easily taught, however.

The upshot is that it's fairly easy to consider each piece of code you're going to write in terms of preconditions and postconditions, write tests for them, and then implement to fit the test(s). If there's a bug or change, you can easily modify the tests first to fit the new pre- and postconditions, then change the implementation. Fast response times plus great test coverage.

The only problem I can see is that a large number of developers aren't in the right mindset to strike a good balance between design/test/code cycles, and it's damn difficult to teach that, especially if the developer does not want to try this approach, perhaps because he/she can't see the benefits.

Having said that, forcing developers to follow this approach may even be counter-productive. A badly written unit test is about as useful as someone testing code by trying out manually whether a single common use case works as intended.

The problem isn't one of choosing the right kind of process to follow, it's one of having the right developers. Some kinds of developers achieve outstanding code quality by writing unit tests first, for each piece of code they implement.

Re:You don't ship test code

[poot_rootbeer]

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

Neither are design documents or sourcecode comments, but I hope you're not suggesting that work done on those portions of a project are an unnecessary waste of time.

You need developer buy-in to make a largescale standards effort work.

I'm pretty sure the submitter understands that, which is why the question being asked is HOW to foster developer buy-in. Your answer to that question seems to be "get rid of anyone who doesn't buy-in and replace them with coders who do", which in a lot of real-world cases translates to "lose your smartest programmers, and substitute in their place a bunch of PFYs". That's not a realistic solution.

Re:You don't ship test code

[Penguin's Advocate]

Write the test first, then write the code. You shouldn't be changing the tests to fit the code.

Re:You don't ship test code

[Marxist Hacker 42]

And that's a *very* good point: For each new best practice, one should add one month to the deadline of any project currently in development, complete with salaries and training time.

Re:You don't ship test code

[chromatic]

The entire point of this argument though is that any competent developer already checks for all of the cases they can think of, so any unit test they write will automatically pass their code.

I've seen that happen too, but that's not Test-Driven Development. Nearly every unit test I write during TDD fails. That's the point. If one passes, it's a surprise and a warning that I overlooked something.

I do agree that it's useful to have someone other than the original developer try to break the code by coming up with edge cases and common error patterns. Pair programming tends to help there, but there's also room for exploratory testing done by an experienced QA person or a cautious and paranoid developer.

Re:You don't ship test code

[dubl-u]

However, if specs cannot be trusted from the outset then how can they possibly be useful as the basis for unit tests? Your work to get those tests working will be wasted since you will end up reimplementing them as the specification morphs and solidifies.

The answer is that you work in small units. That lets people focus and get something done. And it's important that those small units of work really let you get something 100% done, some small but complete shippable feature. Personally I prefer those units of work to be no longer than a week. That involves slicing the work differently than most people are used to, but it's worth the effort.

How do small units help? If the suits have said "these 3 features are the top priority for the team this week," then we all have an interest in nailing down the specs for this week's work. Because it's small, it's easier to think about. Because it has to be done by Friday, there's pressure to keep things simple. And in the few days I'm working on something, requirements won't change much. So I just write my unit tests and my code and I'm good to go.

Sure, next week they might change their minds, in which case I've got to change the tests and the code. But that's fine from a business perspective: things change, and we have to live with that. (Some people worry about thrashing, where you do and undo things all the time, but I've never seen that happen; the "what's most important this week" focus makes suits spend developer labor carefully.) And it's fine from a technical perspective, too: changing a code base that's got good tests is much, much easier than changing one without.

Agile methodology, at least as commonly practiced, to be nothing more than the common Waterfall methodology with a stronger emphasis on up-front test development and shorter milestone cycles.

Yes, that's what I think of as Fake Agile. For a while Waterfall people just ignored the Agile stuff. It wasn't like a lot of them were doing Waterfall because they had carefully considered the options and declared Waterfall the best; it was more about conformity to norms. Now enough people are having success with it so the conformists can't just ignore it. But the easy thing is to tinker a little and declare yourself Agile, so that's what they're doing.

Maybe I haven't drank enough of their Kool-aid, but any methodology that prioritizes test development time above code development time assumes too much, IMO.

They don't want to be handing out Kool-aid, really. Agile methods get a lot of their effectiveness from thinking developers who take control of their work and change things to maximize productivity. The basic message of a lot of the Agile luminaries is, "This is what works for me. You should try it and see if it works for you."

To your specific point, the priority of writing tests above production code is only apparent. The main goal is sustainable long-term productivity. Writing code without tests gets you a short-term gain with a long-term cost. Thus, the agilistas only write tests because it helps them go fast.

Really, all good developers test their code, if only manually. When working on something, pretty much everybody makes sure it works. Maybe that's via debug statements or little command-line doodads or by clicking through the app or stepping through in the debugger. The difference with the Agile stuff is that they say you should automate those tests. That way instead of you having to manually check something every time you worry about it, you get the computer to do all the worrying for you. Instead of keeping the important knowledge about a system in your head, you record it. But not in docs, which require a human to verify them. Instead, you put it in code and make Moore's Law your friend.

Re:You don't ship test code

[dubl-u]

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.

I think you're conflating two kinds of testing. To me, unit tests prove that the code does what the developers think it should. Acceptance tests prove that it does what the product managers think it should. Both kinds of testing are useful and necessary. I agree that testing your own code is a problem, but I think an external group is the wrong way to solve that; the feedback loops are too slow -- you learn about problems in hours or days rather than minutes or seconds. Instead, what works for me is Test-Driven Development, Pair Progamming, and collective code ownership.

Test-Driven Development is where I go through 2-10 minute cycles where I write a little test code, make it pass, and then tidy loose ends. Because I write the tests before the code, my tests aren't just verifying things I already think are working. And with Pair Programming, where I and another guy trade the keyboard back and forth every few minutes, I get somebody who keeps me honest and finds the cases I'm not thinking of. That is supported by changing pairs every few hours and having the team share ownership of the code base. If it's everybody's code, then it's a lot harder to think I'm going to clean something up in that imaginary time called "later". When I check it in tonight, somebody else may work on it (and grumble about it) tomorrow morning.

[...] 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.

And there we have the real problem. If the managers let things get to the death march stage, they've already made clear that their priority isn't actually doing good work, it's getting something out regardless of the quality, and favoring the appearance of progress over actual progress. I am fed up with people who say, "Quality is our highest priority -- except for all our other highest priorities." That way leads to poor quality and poor productivity, along with poor morale, high turnover, and immense waste.

Re:You don't ship test code

[sohp]

Are you familiar with the phrase "flip the bozo bit"?

Re:You don't ship test code

[Anonymous Coward]

However, if specs cannot be trusted from the outset then how can they possibly be useful as the basis for unit tests?

Gross, gross misconception. Unit tests are really for checking the code does what you think it does and making sure nothing unexpected happened after a change. Spec checking is kind of split up between unit tests and the QA dept.

Re:You don't ship test code

[Anonymous Coward]

>While I do agree that many QA departments are staffed badly with people who are ill-qualified, I find the attitude that they are "little better than monkeys" atrociously condescending...Unit testing code is similar enough to testing that repurposing a handful of development-oriented QA engineers for unit test development would allow extra breathing room for the code developers and the increased code quality would see to it that the QA cycle went smoothly. Are you going to argue that better unit tests are going to be worse for the product cycle?

Give me a break. I'll give you even odds that I've been advocating that software QA teams actually live up to their name at least as long as you've been in the industry.

However, I am also a realist: As it stands in industry, QA is a low status, low pay, and intensely repretitive job, that most people with development skills won't touch. The bulk of the people who choose it as a career reflect that. They are not versed in either the theory or the practice of development and are even less capable of creating effective unit tests than developers. (Nor should they necessarily be, QA is a profession in and of itself.) The people that can are incredibly rare, much rarer than qualified developers.

Creating unit test developers just attempts to paint over the same offloading of scut work with a pretty job title. No "real" developer is going to want that as a career. (I sure don't see you volunteering.) The only sane thing to do is to distribute the unit test work among the development team.

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.

Re:What I'd Do

[mattwarden]

Maybe you were kidding, but just in case you weren't: this is a horrible idea. It ignores the cost of turnover to the business (huge!). It's much better to get the employees to buy-in.

Re:What I'd Do

[hahafaha]

Yes, I was kidding. Also, most people who refuse to switch programming practices are either:

1) Senior programmers who have been working there for a long time (and so firing them poses problems)
2) Good enough programmers that they can easily find another job (and so you need them more than they need you).

Advance notice

[MeanMF]

Make sure you give your programmers two weeks notice about the changes...Because that's probably what they'll be giving you soon afterwards.

There's the old stand by...

[__aaclcg7560]

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?

Do it or be fired isn't cutting it anymore? At one job I worked at, you would get a verbal warning, a written warning and terminatio if you didn't follow the new security practices. All that did was to encourage people to find a better job. Since one co-worker already had a job lined up, he blantently went out of his way to get fired by violating all the security rules. Took management a week to figure out what was going on since they weren't following their own security practices. Needless to say, the red-faced manager was not fired for this week long oversight. Go figure.

Re:There's the old stand by...

[mabinogi]

The trouble is, the moment you start firing people over something, other people start wondering if it's really worth working in an environment like that, and start leaving.

It's particularly bad if they're really not convinced the new practice will provide any benefit, and feel that their objections are not being listened to or taken seriously.
If you want to keep good employees you have to treat them like human beings, otherwise they'll go find somewhere that does respect them, and you'll be left with the McDonald's rejects who are used to being ordered around like misbehaving school children.

Incremental change.

[Anonymous Coward]

Bring new development practices in incrementally. Make sure there is a strong case and rationale for each new practice. Equally important is communicating this rationale to the Engineers. Management/programming leads need to step in and raise the whip if needed. Engineers either follow the new standards or find new employment.

Many development practices show immediate tangible benefit. Anybody who has tried moving/renaming files or directories in CVS can easily be sold on Subversion. Bonus points in Subversion's command line client being syntax-similar to the CVS client.

Re:Incremental change.

[CxDoo]

Anybody who has tried moving/renaming files or directories in CVS can easily be sold on Subversion. Bonus points in Subversion's command line client being syntax-similar to the CVS client.

Actually I was considering Subversion for a while, but the deficiencies of externals compared to CVS modules killed my enthusiasm. We have a bunch of overlapping projects and I just don't see how to handle that reasonably in SVN.

Evangalize

[ubergnome]

It's been my experience that most good developers will adopt a standard practice because a) it makes sense and/or b) the new standard doesn't require any more effort than the old way, so it doesn't hurt to play the game.

So, make it easy to adopt and make an effort to educate.

Remember, though, that this is a two-way street; if it's hard to adopt or hard to argue for, then maybe management/architects should rethink their reasons for requiring the standard.

Also -- a training program might be a good carrot to help get the more junior devs onboard (at least with more complex standards like unit testing or patterns-based development).

Re:Evangalize

[Anonymous Brave Guy]

Remember, though, that this is a two-way street; if it's hard to adopt or hard to argue for, then maybe management/architects should rethink their reasons for requiring the standard.

That's very wise advice.

I'm currently contributing to a company-wide review of our own testing processes. Someone brought an example of a current manual used by part of our organisation, which ran to nearly 100 pages. I told them flat out that the moment they bring anything close to that anywhere close to our (generally smart and knowledgable) developers, they will lose any hope of credibility and developer buy-in.

Best practices are best practices because they make life better for the teams who follow them, not because some consultant stuck a pretty label on them in PowerPoint. (Of course, depending on individual responsibilities, some people may have to put up with a little more work to make things a lot easier for some of their colleagues for an overall net plus. However, IME these things tend to work in cycles, so if everyone buys in to help others out, then everyone ultimately sees some benefit.)

Try some structure

[Anonymous Coward]

Keep you process changes to 3 monthly cycles (or something regular), so that people know they're coming. There's nothing more aggravating as a coder getting yelled at for some new process that some guy thought of last week and just 'mentioned' to some people.

If you have a regular release cycle (like any good software product) and actually notify people of the changes (as well as providing a reference guide containing all current policies), people are more likely to follow them. If you just announce new things you want people to do as you feel like it, and don't even bother to document what you want them to do, all you're going to do is piss people off. When you're making up new practices all the time and then ripping into people for not following them, it just feels like you're looking for excuses to pick on them.

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

Re:Beat 'em over the head

[harves]

I agree fully with this, and you also see this happen in smaller open source projects. The maintainer is the guy who ensures that everyone commits correctly, uses standard code formatting, has sufficient documentation, etc. One of the biggest eye-openers for me was when I submitted a huge amount of code, he reformatted it, restructured it for reusability, and sent it back to me. It just looked so much cleaner.

One thing I would also suggest is that, whoever becomes the maintainer for your team gets to set the code formatting and version control requirements. The maintainer is the one who has to enforce them, and by enforce I mean "sit down with the other developer and fix things for them". It naturally stops the maintainer from holding people to ridiculous demands, as they would only increase his own workload.

Tangible business value

[Schraegstrichpunkt]

Some are small, like the use of Camel Case for function names, while others have tangible business value

If it doesn't have tangible business value, why is upper management trying to dictate it?

If CamelCase matters for function names, then what you probably *really* need is a change-controlled interface between the different components of your system.

Re:Tangible business value

[DudeTheMath]

Consistent naming, spacing, parenthesization, indentation, etc., do have tangible business value.

I am a very visual person. I suspect many other mathematical/programming types are as well. Looking over a mish-mash of code from several developers, each of whom has his or her own perferred naming convention, or doesn't worry about lining up curly braces, or is happy to slap new code right up against the left margin, slows me down significantly when I have to go in to add features. As one of the top programmers in our company (our VP of new product development has told me in reviews that I'm probably the best programmer we've got), that slow-down is real dollars to my employer.

Would it slow you down to change to a consistent programming style? Maybe for a week or so, until it's a habit. But having everyone in the company fluent in a company-wide style (especially one that can be implemented across all languages used) speeds up everyone's development, which is a tangible benefit.

Re:Tangible business value

[AuMatar]

Dead wrong. Forcing people to code in a way thats not natural to them costs time and effort for a negligible to no gain. Then you have further losses as people argue about what the one true style is, as people try and get it to change, and for anal assholes to go through and enforce it. Its a huge net productivity loss. You might have a point within a class/function/file, but having a company wide policy is pointless, and will just cause efficiency losses. In fact its on my top list of red flags- when management starts worrying about shit like that, you know the place is turning into a hell hole and its time to leave.

Re:Tangible business value

[DudeTheMath]

I may not have been entirely clear. Management is not worrying about it; my fellow developers and I are. This is a relatively small shop, and at least half (the ones I've talked to about it) agree we should have some standards; two newer employees asked me why we don't ("Because we're such a small shop.").

Sometimes I have to maintain code that, visually, is a pile of crap. (Some of it I wrote myself, years ago.) In the process of trying to understand it, I essentially run it through a "prettifier," but those aren't perfect; any edit has the potential to introduce error. All of us want to be able to walk into anyone else's code and follow the logic. It's not about being Big Brother: it's about making each other's lives easier.

It's all about readability and maintainability. Most of the things I'm calling standards can be handled by everyone using the same preferences in their IDE: Set indent to x, auto-indent blocks, replace tabs with spaces. So I'm not "forcing people to code in a way thats [sic] not natural to them." I'm asking to take underscores out of variable names, which are harder to type than simply capitalizing a new word in the name. I'm asking to add white space around some punctuation (except parentheses).

That's really about it. How does that interfere with your coding? For about a week, you might have to think about it; after that, it'll be habit. The gains across your team(s) will far outlast this brief adjustment period.

Re:Tangible business value

[Anonymous Coward]

which are harder to type than simply capitalizing a new word in the name

I respectfully disagree with your logic. It may be easier for you to type, but I find underscored names much more visually appealing. Then again, I mostly program in C where camel-case is looked down upon. I'm guessing you use C++, C# or Java?

If it matters, make a tool to do translation (or at least validation) at check-in. One rather simple method is to examine the symbols exported and use the link editor to remove any that do not comply with company policy. That way any developer not using the prescribed standard will be in for a nasty shock when he tries to link the executable. As for your whitespace gripes: a simple trick is to require check-ins to fully round-trip with some prescribed settings on indent: only accept the check-in if foo.c doesn't differ after being indented. You can also run gcc -E and then run a tokenizer looking for invalid names, or run gcc -c and use nm to find invalid symbol names in the interface.

Re:Tangible business value

[AuMatar]

No, its not about maintainability. Using camel case or underscore is not a maintainability issue. Nor is wether they use 2 space, 3, 4, tab, etc (ok, if you have someone using a tab on one line and spaces the line immediately under it, you have a small point. But all you really need is the same style within a function, and it doesn't matter which style is used).

Basicly, you're trying to force your style on everyone. You find camel case easier to read. Other people find with_underscore easier to read. You find x spaces easier to read. Others find tabs easier. You find it easier to read with punctuation around operators. I find it harder- it makes the text less dense, and forces you to break if statements onto multiple lines or word wrap (I hate that). You aren't even consistent in your logic- you say it'll soon become habbit. If so, why hasn't reading other people's styles become habit for you already?

Coding standards should be about things that actually increase maintainability- unit tests, meaningful names, eliminating (or reducing to where they're truely needed) language features or patterns that can be difficult to undestand, etc. Requiring N spaces and variables to be named via method X does not make the code any higher quality. It won't save you a day of maintenance. In fact you'll lose more time discussing it in the first meeting than you'll ever save from it.

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.

Re:Performance tracking with bonuses

[poot_rootbeer]

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.

Oh, yuck.

What happens when it's 7:55 and the component I'm working on is nowhere ready for compiling? Under your system, there seem to be two options: check my broken code in and ruin the compile, or fail to check my broken code in and receive demerits AND ruin the compile.

The obvious third option -- run the compile but use yesterday's working version of my component instead of my currently-broken one -- seems to be absent.

Re:Performance tracking with bonuses

[rossifer]

We use Calavista which queues up commits and only allows a commit to occur if it passes an acceptance script. Our acceptance script does a build and a run of the unit tests on a fast machine. You could also run a convention compliance/code quality analysis tool as well. With this system in place, it's pretty much impossible to "break the build".

I really prefer this system to a "you broke the build" notifier. It's certainly better to quickly know the build is broken instead of the next day, but other people are still stalled while it gets fixed.

Turns out that this was very good motivation for us to keep the unit tests speedy. When we first started using Calavista, the unit tests took twenty minutes to complete. It was quite painful to have to wait forty minutes for two other checkins to complete, so we decided to take an iteration and work on testing performance to make the unit tests faster. Two weeks later, a few obvious performance problems were solved and a better set of unit tests (more coverage) could be built and executed in under five minutes. The unit tests continued to grow from there, but we never let them get above ten minutes, and considered eight minutes to be the "danger" zone where we needed to take a look at test performance again. Now, we have 2500 unit+functional+integration tests (running against a live database) running in 7.5 minutes. Seems to be tolerable to wait 15 minutes to see if your commit worked (only very rarely does the queue get longer than 3 simultaneous commits, usually around the end of the day).

Bias warning: some good friends of mine are employees of Calavista and I do very occasional development for them on a consulting basis.

Regards,
Ross

Re:Performance tracking with bonuses

[Chacham]

What happens when it's 7:55 and the component I'm working on is nowhere ready for compiling?

Considering 7:55 is well after the end of a workday, the person had a few hours to fix the problem. And if this happens once or twice a year, the OP said its ignored. If this happens weekly, it does point to problem with the coder.

The obvious third option -- run the compile but use yesterday's working version of my component instead of my currently-broken one -- seems to be absent.

If it is a new component, this does not help. Though, to work with this system, i'd first create a stub that just accepts input, and gives standard output. After that works, start putting in the logic. If the logic is not ready on time, comment it out. If the logic is too weildy, it should probably be in a separate function anyway, and the coder needs to learn a better coding style.

If it is an old component, the old component is already submitted, so there's be no reason to change it.

Re:Performance tracking with bonuses

[KU_Fletch]

If your work isn't ready to be compiled, you can simply revert the build machine's copy to an earlier version. The important part is that you just get it in. If it can't check out your files for compile, the compiler breaks. Nobody really puts anything onto the build server until it's in a usable state for our projects.

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.

Tell them why it's important

[Grave]

If there is an actual benefit to the company/group/process as a result of the change, they need to understand it. If you cannot explain this benefit to them, they will not bother with it. But if you cannot explain the benefit to them, you need to go back and re-evaluate why that change is happening in the first place. Sometimes you may find that someone understands the reasoning behind a new practice but just doesn't care. If their failure to implement it hurts the entire team, they should be aware of this. If they still don't care, and this new practice is worth implementing anyway, ask them to try it your way for a bit and see how they react to it. If they refuse, tell them that they are a valuable asset to the team, but only if they are cooperating, and if they won't adapt to this change then they might not be able to continue working there. After all, if this new practice is truly beneficial to the group, then the old one is no longer acceptable behavior.

Most of the time, once someone understands why a change is needed (and this isn't just you telling them the reason and having them nod their head -- they need to repeat it back to you in their own words), they will gladly go along with it. Those who still refuse are probably not worth having on your team.

Re:Tell them why it's important

[X-treme-LLama]

I agree completely.

Too many times I've worked at companies who forced down changes, seemingly just for the sake of change. Employees are wary of that. Often times it's easier as a group of employees to ignore the changes until people stop caring or they go away. Especially when they're ignorant and/or counter-productive.

I don't mind change, but explain to me why it's important. What happens if I don't do that way, and not just "you get fired", but a real explanation. If there is a good reason for it, and it's not just because some manager is jerking off to the latest idea he read in some industry rag --err mag--, then people will generally happily comply. Those that don't do deserve to get fired. But most of us just want to know we're doing something for a real reason, and that it's worth doing.

My 'work' concerns, if I like the job, are in this order: Myself (so I don't get screwed), protecting my ability to do my job effectively, my coworkers, and finally the company. Don't screw me, don't make my job harder for no reason, don't mess with me and my coworkers as a group, and don't do things that aren't helping the company. After all they are writing my paycheck, not some idiot in middle-management who attends meetings all day and is trying to figure out how he can get his next bonus.

Re:Tell them why it's important

[eric76]

Some changes are so ridiculous it's hard to see how people came up with them.

At one company, it was decided that we would use "3 space tabs".

I thought that was a really stupid rule and never went along with it. When I send a program to the printer, I expect it to print properly "as is" instead of having to use something else (Visual C++) to print it.

The guy that suggested using 3 space tabs went from to Microsoft when he left that company.

Re:Tell them why it's important

[X-treme-LLama]

3 makes perfect sense! When 4 is too many and 2 isn't enough.. Also when you're *insane*...

Why 3, was he counting from 0? Did he mean 4? Or was it one of those, we'll save 1 byte per line times X lines, the storage space spavings alone will be worth pennies! Not to mention the fractions of a second people will save! Except the poor bastards who have to update all their existing code...

Craziness.

Thank you

[Anonymous Coward]

Thank you so much for not saying "begs the question". Hats off to you. :)

Re:Thank you

[kfg]

As I told the officer, "With all due respect, Sir, it isn't begging if I'm not soliciting."

KFG

Send out memos

[LordEd]

Um, yeah... its just that we're putting the new cover sheet on all new TPS reports, so if you could just go ahead and remember to do that that'd be great, yeah...

Did you get the memo?

You don't ship Eiffel code

[Anonymous Coward]

There are also languages like Eiffel were design by contract makes unit tests an integral part of the process. Not afterthoughts that get seperated from the code like other languages

Re:You don't ship Eiffel code

[Anonymous Brave Guy]

Assertions and compile-time safety, whatever you choose to call them in your particular language, are not unit tests. They are simply tools. Just because you code in your preconditions, that does not mean you are unit testing your code. You still need test cases that would trigger those assertions if something was wrong.

the best best practice

[russellh]

the number one best practice: do something that matters. when you do, you can hire great people that really care. when people really care, they do it well and can be trusted. I know there's this whole "reality" thing that sometimes gets in the way, but reality isn't why I'm posting to slashdot at 1 am. I quit my programmer day job six years ago to raise the kids. that's what matters to me.

this may sound odd

[ILuvRamen]

well this may sound a bit odd but trust me, it works. If you try to change a couple things, they'll of course reject it. But if you change a bunch of unimportant things too, it will actually encourage them to change overall. It's kinda like telling someone to clean this room then that room and organize their FPS game CD's in their house and they never really get to it but then they move into a new house and since the whole environment is different and better, they act different and finally do what they should. So first, give the whole set of changes a name; I don't care how stupid it it cuz historically, it works. Then change every insignificant thing you possibly can. Paint the office, move stuff around in the break room, get ppl new keyboards, and redo the company newsletter layout. With so many changes, everyone will be thinking "hey, those are a lot of changes" and it will become more premonent in their minds and they'll be more active about noticing the changes and coping with them accordingly. Then sneak all the guidelines for new policies or things you want to change in there somewhere and stick to them and enforce them heavily and keep linking them to the overall changing theme and you'll have massively better results. I'm sure I pretty much murdered that strategy compared to the textbooks I read about it in but hopefully you get the overall idea and seriously, it works! Now mod this post already, it's more usefull and thoughtful than the average one!

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.

Re:Machiavelli

[Chacham]

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.

Bad idea. That will alienate even more people.

A better idea would be to be very open about changes, but takes a few months to implement them. During the first month it should just be a topic to talk about, and see what the feedback is. If it is rejected, drop it (and perhaps come back with a modified form a couple months later), if people want it, they'll adopt it themselves, if people accept it, but are wary to implement it, start voluntary implementation in the second month, and let people fit in over one or two months. Then, help the stragglers by *slowly* putting the pressure on them, making it more difficult not to comply.

Easy come, easy go, works with changes. Changes adopted slowly are more likely to stay, but then work with the employees to implement it.

Re:Machiavelli

[dubl-u]

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.

I think there are two other ways around this. One is that if people are making the change on their own to solve something that bothers them, then they see it as a positive rather than a negative. So a good manager doesn't impose a change in somebody's working environment, but rather helps people to notice the problems they have and to suggest solutions. The other is to have a continuous level of moderate change. If every week you do a retrospective and say, "What do you guys want to do differently next week?" then people will get used to the change and resent when you try to stop.

Get them involved

[thsths]

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

You have to get them involved in creating and writing the practices. You said yourself that they are smart folkes, so ask them what they would like to have improved. This is not always easy, and it is certainly difficult to reach a consensus between a lot of smart folkes, but it is absolutely essential.

If you just want to know the best way to prescribe your favorite coding styling, and your are afraid that it may get into the way of the engineers' daily work, then forget it.

My opinion

[WetCat]

Buy some expensive (and so looking) chocolate and establish a weekly bounty for engineers who follow standards.

Re:My opinion

[aadvancedGIR]

I saw it the other way around.

The team had a very ugly dragon-like teady bear and each time someone commited a bad code, he got to have on his screen for the week. Of course, everyone was encouraged to ask him what he did to deserve that shame.
It was very efficient: everyone was trying hard to avoid making mistakes, and if someone did one, all the other coders could also benefit from the experience.

Make sure the practices help rather than unhelp

[mrjb]

The main problem I see with adapting new practices is that project management relies on discipline as a replacement for motivation. This Does Not Work. Discipline alone is not enough- This is why for instance source control systems have been invented.

At some point at our company we started 'crosschecking'- which essentially means all developers have their code tested by another developer, mostly before things got to nightly build. (Other quality assurance practices are also already in place).

The result was twofold. First of all, incorrect code was communicated back the same day, or even several times the same day. This saved a huge amount of time in detecting problems. Second, because each developer knows their code is going to be reviewed by another developer, they try harder to avoid the bugs in the first place.

The first release after we introduced this practice, we noticed that the bugs being reported by the client mostly had to do with previous releases. The bug rate has steadily decreased since, and we're not constantly patching holes anymore. We catch most bugs before we deliver the product to the client- so the client is happier too. We spend more time doing 'fun' stuff now, rather than bug hunting. And it is quite an ego boost to ship a product and not hear of any defects. Would we stop crosschecking, we would have the feeling that we are shipping an inferior product.

By making sure the practices to adopt are insanely useful, time savers and make the work more fun, developers will adopt them without complaining.

Re:Make sure the practices help rather than unhelp

[triffid_98]

An infinite amount of unit testing cannot guarantee an absence of bugs?

But perhaps I am a bit jaded since our company considers one of it's major advantages an all encompasing in-house framework that makes it neigh impossible to unit test most of our modules individually...

On that note I'll make the fairly obvious observation that leaky abstractions (ie. nearly all in-house frameworks) make code both harder to build and harder to maintain, though it's obscure quirks ensure that I'll be able to keep my kid in diapers for the forseeable future.

Boss #2

[oSand]

I hear you're having some trouble with your TPS reports

Give them inscentives.

[SanityInAnarchy]

On the same note, give them inscentives to not only adopt these practices themselves, but also spot others not doing them.

I'm making this up on the spot, so feel free to actually make it into something worthwhile:

Create a ficticious currency, or some sort of point system. Report someone accurately as doing something wrong, and you get a point. If you're doing something right, you get a point or two. Get caught doing something wrong, and lose a point. At the end of the week (or other time period), give something relevant to the person with the most points, at every level. (So, for instance, at the level of a 10-person sub-sub-sub-project, you'd probably give the winner a beer of the week. At a company-wide level, but somewhat less frequently, well, depends how much you want to do -- a little bird told me that Google has some really cool inscentives, like cars and vacations, for people who really get stuff done.

Re:Give them inscentives.

[Omestes]

Actually this isn't such a bad idea, except for the reporting people part. This would bread suspicion, and thus a less than optimal environment. Purely positive enforcement (psychologically) would be the best, basing rewards purely on merit. Though in the work context penalties for bad output is also fair.

Re:Give them inscentives.

[AuMatar]

Yup, because I want to work at a place where all my teammates are scanning my work for places to rat me out to management. Sounds like a real winner.

Now the opposite way may not be bad- allow coworkers to nominate people doing an exceptional job. But going the way you mentioned is just going to create an atmosphere of mistrust and CYAism.

Re:Give them inscentives.

[SanityInAnarchy]

Perhaps, and I don't think it'd be a good idea in the long run. However, it would be a nice kick in the pants if you discover that people are still being fundamentally uncooperative.

re: builds

[oSand]

Try the you break, you bought it approach. The offender becomes the new build engineer

This is Simple! Three Easy Steps

[under_score]

1. Management asks the engineering group to come up with a proposal for solving a problem.
2. The engineering group comes up with a standard.
3. Management supports the standard and holds the engineering group to its commitment.

For any standard you can think of, this will work most effectively. The only problem is that I lied about it being three _easy_ steps. Each one is actually really hard to do and you just won't have any success with rolling out new standards until you get good at each of these things.

Until then, coaching, training, badgering and firing might get you part way.

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

OT: Granularity of checkins

[realnowhereman]

I would say that if it is even feasible that every check in could include a unit test then you are checking in far too infrequently.

Move to a decent version control system - git is my favourite, but I'm sure mercurial, darcs or bzr-ng would be fine too.

I used to use version control only to check in large relatively complete changes. I now realise that that was completely missing the point. I now constantly check in, every patch is small and easily read. The description that goes with it is easy to write because the patch is small; best of all though is that merging and cherry picking are suddenly hugely powerful because you can be very precise with which patches you use.

Oh - and if management ever says "and what do you do exactly"; it's lots of fun to supply a log dump that tells them. :-)

Re:OT: Granularity of checkins

[nasch]

I would say that if it is even feasible that every check in could include a unit test then you are checking in far too infrequently.

I'm worried about your unit tests! I doubt you could show me a change so small it cannot be unit tested.

Oh - and if management ever says "and what do you do exactly"; it's lots of fun to supply a log dump that tells them. :-)

Does management find that useful?

Unit testing is good, but not everything

[Anonymous Brave Guy]

Testing isn't something that should be done at the end with your fingers crossed. Defects cost more to fix the longer you wait to have them exposed.

True on both counts, but these principles cut both ways: testing is also not a substitute for planning and maintaining a good overall design, and if your entire process revolves around the unit testing practices then any discrepancies between the (probably not crystal clear) requirements and what your unit tests expect are likely to be discovered horribly late in the process.

Re:Unit testing is good, but not everything

[nasch]

if your entire process revolves around the unit testing practices

True, but a strawman. If your entire process revolves around just one thing, no matter what that thing is, you're in trouble.

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:Test-driven development

[rossifer]

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.

That's just foolish. The passing test suite just mean that whatever was tested is still working. If you have really good code coverage with your tests, you can have a high degree of confidence that a refactoring introduced a small number of bugs. If you have poor coverage, well... whatever is tested is still working. I was introduced to TDD with the philosophy, "You can only assume something is working if there's a test to verify it."

When the testing glass is half empty, your worry and attention tends to focus on what is missing instead of being confident about what is already there. That's the stuff you don't have to worry so much about.

IME the hard-core TDD advocates also have a false sense of security when it comes to design.

IME, there are plenty of coders who feel that testing can make up for their lack of design skill when they're ready to lunge in and refactor some code they don't like. Most TDD people I know (there's a selection bias there, so bear with me) have a healthy understanding of risk, bugs, and the various balances between high-level design, low-level design, coding, and testing.

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

Agreed. XP really shortchanged a lot of teams with the oversimplified observation, "The simplest thing that passes the tests is all that you need." It's actually, "The simplest thing that an expert designer would build knowing everything he does about the history and immediate future of the system that passes the tests is all that you need." When that person has two possible designs, choose the simpler one. Both options will probably include some extra complication to gracefully adapt to future changes.

Regards,
Ross

Re:Test-driven development

[nasch]

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.

Then the test process is broken. Meaning, you deployed to a supported environment on which the tests were never run. If you had run all tests on all platforms, then that one would have failed, and the developer would be notified of exactly what happened. This is the great thing about automated tests - it doesn't matter if it takes hours to run them all.

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.

First, TDD is not having "some tests in place". Perfect TDD means everything has a test - everything! Is it possible to have perfect TDD? I don't know, but I think it's possible to come close. Second, is there anyone saying you can design on the fly all the time with no possible cost? If there is, I don't agree - no matter how good your tests are.

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.

I'm not sure what you're saying here. Are you suggesting that TDD means you don't do design work ahead of time? That is certainly not the case. I don't think you're saying that unit tests are the only form of testing with TDD, but in case you are, that's not true either. You still do functional tests just like always, and you still have the same QA. Are you saying TDD leads to bad designs? Maybe you can clarify here.

Not you in particular, but a lot of the criticism and dismissal of TDD here seems to be from people who have never done it, or in some cases don't even understand what it is.

Re:Test-driven development

[dubl-u]

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.

I don't think anybody seriously believes that perfection is achievable. However, they do believe that continuous refinement lets you get closer and closer, and that at some point the risks get to an acceptable level. Were I bitten by your example, I'd take it as a lesson that I had failed to express something important in my unit tests and build environment: code should work on OS X with compiler Y. Were that a risk I worried about before, I'd regret that I hadn't taken the time to automate the worrying.

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.

I missed them saying that. Do you have a reference?

The closest thing I have heard them saying is that test-driven development encourages code that is more modular, more flexible, and better designed than not testing or testing after. It ends up more modular because that's the easiest thing to test. You get more flexibility because as you build you are continually flexing your design in ways that generally are similar to future change, and because you aren't adding things that aren't required by the tests. And you can get better design because you start out thinking about your systems from the outside, focusing more on meaning than mechanism.

As far as I can tell, that's all true. TDD isn't a panacea or the sole practice one might adopt, but every person I've seen adopt it has found benefit in it, both novice designers and experts.

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

If somebody said that and meant it like you do, I'd agree they're wrong. But you're missing one of the most important points: your design shouldn't start to evolve in weeks or months: it should start to evolve from the beginning.

Re:Test-driven development

[Anonymous Brave Guy]

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.

Then the test process is broken. Meaning, you deployed to a supported environment on which the tests were never run.

Not at all. In fact, it was our automated testing processes that picked that one up. But when your automated tests run on two dozen platforms, with the time to complete some test runs measured in days, the automated testing is something that happens weekly, not something individual developers can use every time they've lifted a method or adjusted a data structure.

In any case, this is rather peripheral to my point, which was simply that an attitude that you can make arbitrary changes to code and rely on tests to pick things up is a dangerous one. We have thousands of tests, accumulated over more than a decade, yet they barely scratch the surface of our application's complexity. We're working on mathematical libraries, and there are a provably infinite number of configurations we would have to test to be exhaustive.

In other words, in my world, automated unit testing is handy in that it often warns you about gross errors and lets you know when your approach has a fighting chance of working, but we still need various kinds of formal proof/review, walkthroughs of new algorithms, and the like before we consider it "tested".

First, TDD is not having "some tests in place". Perfect TDD means everything has a test - everything! Is it possible to have perfect TDD? I don't know, but I think it's possible to come close.

Not in my world. Things like proofs of algorithmic correctness, static code analysis tools and code reviews can consider infinite problem spaces. Automated testing is by its nature finite in what it tests. Since you cannot define our requirements in terms of a finite set of tests, you could not approach perfect TDD in our context.

I'm not sure what you're saying here. Are you suggesting that TDD means you don't do design work ahead of time?

I'm not saying that it necessarily implies that, but I am saying that a lot of developers with a poor understanding of the field go down that route because of that false sense of security I mentioned.

I'll comment more on this in my reply to a sibling post to yours later.

Re:Test-driven development

[nasch]

Not in my world. Things like proofs of algorithmic correctness, static code analysis tools and code reviews can consider infinite problem spaces. Automated testing is by its nature finite in what it tests. Since you cannot define our requirements in terms of a finite set of tests, you could not approach perfect TDD in our context.

Or perfect any other kind of testing, either. Sounds like you're in a very unusual niche - normally perfect testing by some means is theoretically possible, if not practical.

A lot of your objection seems to be not to TDD, but to the attitude that TDD solves everything. I'm sure that's out there, but of course that's an idiot problem, not a TDD problem. :-)

Developers must experience a benefit

[Twylite]

Hear hear!

Developers need to experience a benefit from the practices they are asked to adopt, or they will have no internal motivation to adopt them. In that case you are forced to use external motivators (rewards or punishment) which are never as effective.

There are only two reasons to introduce a practice: (1) to improve productivity; and/or (2) to CYA (cover your ass). Any practice that doesn't do one of those is worthless.

Practices that improve productivity should (and generally do) appeal to developers. Such practices usually involve working smarter rather than harder, isolating developers from mistakes or inconvenience caused by other developers, and taking care to reduce mistakes early in the development cycle (so less frustrating debugging at integration time). Take the time to ensure that developers understand what the practice will do for them, and they'll have an intrinsic motivation to follow it.

Practices that CYA are more difficult to implement. These represent business concern about liability that course arise from the way things are being done. That could involve labour issues (developers have been under pressure to work overtime), intellectual property (someone is copying GPL code into the code base), or following industry norms so that you can't be sued for negligence.

Where industry norms differ from the practices that improve productivity you'll need to educate developers and provide some external motivation (usually punishment) to ensure compliance.

Re:Developers must experience a benefit

[Abcd1234]

Practices that improve productivity should (and generally do) appeal to developers.

Assuming, that is, your developers are skilled and objective enough to be able to tell when this is the case. Unfortunately, it's often the job of senior technical folks to force change upon the less experienced and ignorant, because they honestly have no idea what's good for them.

Re:Developers must experience a benefit

[thsths]

> Unfortunately, it's often the job of senior technical folks to force change upon the less experienced and ignorant, because they honestly have no idea what's good for them.

While it is certainly true that there are more and less experienced developers, you are not exactly helping the "buy in" by calling someone "ignorant". If fact, it is a near sure sign that you would design procedure which seem to make sense, but which actually do not work for the people that have to use them.

So if you want to have working procedures, you need to ask the people affected by them first. Everything else is a vain waste of time.

Re:Developers must experience a benefit

[Abcd1234]

Ummm, I *am* a developer. Trust me, I know plenty of people in the industry who honestly have no idea what good programming practices are, or why they are beneficial. Ask one of these people to write unit tests, and they'll respond with "but that wastes my time when I could be writing code", or "my job is to develop, not test". These people *are* ignorant. And whether you like it or not, they exist, and in my experience, they're far more prevalent then I would like.

IMHO, development practices should be designed by senior members of the development staff with input from the rest of the team. However, this should be a request for input, not permission, which is what it seems you're implying.

Try the Six Sigma approach

[cavemanf16]

You need to overcome differing viewpoints and resistance to change which is obvious, but a non-obvious way to help you evaluate why the resistance to change exists and how to overcome it can be done through a "stakeholder analysis". See Table 1 from this link: http://www.isixsigma.com/library/content/c030708a. asp and the section just below that table called "putting improvements in place".

Many organizations (including my own) are guilty of making changes to process and procedures without fully involving the stakeholders involved in performing steps in those processes. If you want to be successful in making useful changes, always make sure to keep your stakeholders involved in helping understand the reason that the change is needed, and how the proposed change will benefit the organization (as it may not always appear to benefit all of the stakeholders of the process). A feedback loop on measured improvements to a process or procedure is always a beneficial thing to keep those involved in making the change happen encouraged that the new way of doing things is the right way to continue doing things too.

Re:Try the Six Sigma approach

[anomalous cohort]

Correct, and the developers are also stake holders. Nothing achieves compliance like buy in which is accomplished by having the developers participate in the establishment of best practices. Use pain points to motivate the establishment of best practices. For example, the next time you hear a developer complain about the lack of documentation on a particular component, suggest that the establishment of a developer wiki board could be a good best practice to introduce.

Oh Bog, how I hate the phrase "best practices"

[Dammital]

Excuse my nitpick, but I just endured a staff meeting yesterday where the CFO prattled about "best practice", "best of class" and "world class" information systems. I sat biting my tongue, absorbing this puffery while the bullshitometer pegged.

Feel free to tell me how you want things done. You're the boss, and you pay me to do things your way. But do take responsibility for it! Nobody is buying your decision as so-called best practice as if you had just carried stone tablets down from Mount Sinai.

I mean, who labels things "best practice" anyway? The UN Commission on Best Practices? Best Practices Magazine? The Best Practices counter at your local Kroger? Bah.

(Sorry. I feel better, thanks for asking. In retrospect I don't know if the above should be modded flamebait or troll. There should be a "catharsis" mod, but I guess we have to work with what we have.)

Re:Oh Bog, how I hate the phrase "best practices"

[thsths]

> I mean, who labels things "best practice" anyway?

"Best practice" is a ridiculous phrase. It does indeed sound of Mount Sinai, but all it means that this is the best way of doing business. Once you translate it, a lot of the bullshit is not nearly as scary any more.

"We should really follow best practice." -> "We should really do things the best way possible." (kind of a tautology, so everybody nods, but nothing is actually said.)

"Our best practices are ..." -> "Our best way of doing business is ..." (How do you know? What you really mean is that you hope ... is the best way of doing business, and you hope everybody is doing it.)

"Best practices would require ..., but we can't do that." -> "The best way we can do this is ..., but we can't do that." (This is an obvious contradiction in terms, but still everybody is expected to nod.)

Peer review

[Chelloveck]

(e.g., the revision control system could reject check-ins without unit tests)

This won't work. If people aren't willing to do the job, you can't force them through automation. Ever see a shop where they just adopted the practice of "all checkins must be accompanied by a change log"? 90% of the change log entries end up being "Fixed a bug." If the developers aren't willing to write unit tests, the need-a-test-to-checkin requirement is going to generate a lot of unit tests which unconditionally print "hello, world" and return success.

Peer review is probably the best way to enforce this kind of practice. Require that someone else reviews and signs off on the change. It doesn't have to be the project lead or anything like that. Just have another developer look it over to make sure nothing is missing, and is willing to sign his name to that fact. Very few people will take responsibility for someone else's blatant omission, so I doubt you'll end up with a lot of collusion to cheat the system. ("I'll sign your incomplete commit if you sign mine.")

And, of course, if you can get the peer to look at the actual substance of the change beyond just the format, you're way ahead of the game.

Now, I have to go write a unit test for a 2-line fix I made yesterday. (Really. Even though it annoys me to spend hours writing a test for something that took me 60 seconds to write.)

You're doing it wrong

[dubl-u]

A big part of my living is helping teams to adopt good practices, and I'm sorry to say that you're going about it all wrong.

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.

With this attitude you have guaranteed that you will a) probably fail, and b) certainly make things worse.

Engineers generally want to do their work better. If they don't adopt your pet practice, then this means one or more of

• the practice is not as good as you think
• they don't yet see why the practice is good
• their workload is too high, leaving no time or enthusiasm for learning and exploring
• in the past you have done other top-down imposition that have undermined the morale and the sense of ownership needed for changes like this

Personally, I think managers should never be imposing practices at all. Engineers are better treated as professionals. You should explain the results you want, and ask what help they need in achieving it.

For CamelCase, for example, you should let people responsible for a particular code base decide how to handle that. Give them the time needed to consider the issue, honor the conclusion they come to, and encourage them to check occasionally to see how they like the results of their decision and whether they want to change it.

For unit testing, requiring a unit test with every checkin is foolish. That's not because testing doesn't work; I use Test-Driven Development and have a bug-in-production rate of less than one a month. But by turning a useful practice into a bullshit requirement, you give them incentive for bullshit compliance and undermine trust. Instead,

1. Ask for what you actually want: fewer bugs.
2. Use a Big Visible Chart (yes, paper; yes, hand-drawn; yes, on the wall in a shared space where everybody will see it regularly) to make a bug metric visible.
3. Ask the developers how to achieve your goal. Unit testing will be one of the answers.
4. Ask for a team or project that would like to volunteer to try out unit testing and figure out how to make it work in your environment.
5. Ask them what it will take to make that a reality.
6. Give them what they ask for. All of it. No pressure, no whining about the cost.
7. Come back weekly to ask them how it's going and what you can do to help.

The next typical objection is, "What if they ask for classes and books and a reduced workload so that they have time to learn this? That's unacceptable! Can't they just learn it from a couple of articles on the web with no productivity impact?" If that's what you're feeling, then the biggest barrier to adopting good practices at your company isn't your engineers, it's you.

Re:You're doing it wrong

[thsths]

> The next typical objection is, "What if they ask for classes and books and a reduced workload so that they have time to learn this? That's unacceptable! Can't they just learn it from a couple of articles on the web with no productivity impact?" If that's what you're feeling, then the biggest barrier to adopting good practices at your company isn't your engineers, it's you.

Been there, done that. And I can conclude that it is not only true, but also reality.

Reducing the number of bugs is not going to be free. It is not going to be easy. If you expect it to be, you are doomed from the start.

Re:You're doing it wrong

[dubl-u]

Reducing the number of bugs is not going to be free. It is not going to be easy. If you expect it to be, you are doomed from the start.

I think for the short term, this is completely true. However over the long haul, I think most shops are well away from the optimum, spending more time finding and removing bugs than is efficient. It's the classic, "Well, since we spend 60% of our time in the debugger, there's no way we could afford to write tests." From the stats on my projects, improved quality saves time over the long haul.

Mod parent up!

[frank_adrian314159]

The poster above is dead-on.

Moo

[Chacham]

I really despise things like this.

Programing is art. I've heard so much about standardization, and i see zero benefits. I challenged our arcane non-vowelized database table naming conventions, and was told that's it's easier when everyone uses the same names. Umm, no. There are two reasons this fails miserably. One, it takes time to learn the standard, which noone remembers anyway without working with it for years. Two, the names are incongruous with coding style, and a second programmers will have that much harder of a time getting the "feel" for the design.

I say let each coder do his thing the way he wants to do it, and just demand consistency within his own code.

I remember being forced to meet one standard that i despised. So, i coded my own way and right before submission, i mangled the code to match the standards. I can't imagine it helped, being i was the one to maintain it.

Further, who are the standards for? The maintenance coder? The maintenance coder spends *far* less time on any code than the original coder. And, in most cases, the orginal coder *is* the maintenance coder. Why not let the coder do it his own way, and the maintenance coder, should it happen to be someone else, will spend five minutes learning the new style? Really, it isn't that big of a deal.

This whole thing of standards makes no sense to me. It's not like network interoperability from different vendors, or language barriers that require a known standard. This is people doing their own thing, and willing to help each other to get it done, so why not let them coder in their favorite style?

Camel Case?

[Anonymous Coward]

Camel Case? Is this some sort of ClearCase add on?

This is simple! Implement a reign of terror.

[Medievalist]

First, get some quislings. These will be people unsatisfied with the current status quo. Make sure they have conflicting interests and agendas, like, pick a developer who likes emacs and CVS and another than worships git and vi. Don't tell them about each other.

Next, get some enforcers. These should be brutal, ignorant thugs who like to hurt people. Underpay them and viciously insult them at every opportunity. Lead them to believe that the developers - and especially your quislings - are your favorites. Call the enforcers "The department of productivity enhancement" or something similarly beaureucratic.

Now, using information provided by your quislings, have your thugs brutally torture to death some example victims. (Remember, Machievelli says commit all your atrocities early.) It doesn't matter if your victims are actually guilty of anything, in fact it's better if they aren't, but try not to eliminate any key personnel. Let it be known that any "quitters" or "underachievers" will be targeted next.

Apologize profusely for your previous misjudgement. Let everyone know that you only intend to discipline people who really deserve it in the future. Blame the mistaken murders on bad information, provided by your informants (don't say who they are) and "rogue elements" in the enforcement group. Ostentatiously fire the least culpable and least effective enforcer. As soon as you leave the room, the chief enforcer will explain that "people who really deserve it" are those that do not follow coding guidelines, and "discipline" means waterboarding.

One week later hire an even more psychopathic replacement for the fired enforcer. Have the loudest complainer brutally murdered, but don't talk about it or admit having it done. Stare blankly at anyone who brings up the subject, then talk about the company christmas party.

Your developers will work like the very dickens, and do anything you want.

In my experience...

[GWBasic]

In my experience...

Shared-responsibility code works well. This is where one coder develops a function/class/module, but another developer debugs/enhaces it. It creates a consistant style, because everyone is working with everyone's code.

Allow a little bit of artistic freedom... If you're that uptight about code, have a pretty-printer run at checkin.

Avoid inventing a style guide when there are plenty already in use. For example, when I develop in C# with Visual Studio, I follow Microsoft's style guide and encourage everyone else to. That being stated, sometimes you need a style guide for egotistical morons who refuse to follow establsihed conventions in preexisting code.

It's easy to overdo unit tests an automated builds; ultimatly you need a developer who takes responsibility for the unit tests and build environment. I've been in such a situation before, and I had to occasionally crack a few kneecaps.

Fire developers who throw temper-tantrums when they refuse to follow the sytles and conventions of an existing project. Seriously, someone who can't adapt to different programming techniques is useless as a software engineer or a rank & file coder. (I had to put up with an asshat who refused to use GUIDs in a Microsoft database. His arguing put us behind schedule.)

Ultimatly, you need to trust your developers. Some things are worth getting uptight about, like consistant data access and indexing schemes, and others aren't, like tabbing.