Forgot your password?
typodupeerror

Getting Development Group To Adopt New Practices? 125

Posted by Cliff
from the pain-of-changing-work-habits dept.
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."
This discussion has been archived. No new comments can be posted.

Getting Development Group To Adopt New Practices?

Comments Filter:
  • by BadAnalogyGuy (945258) <BadAnalogyGuy@gmail.com> on Wednesday November 15, 2006 @12:41AM (#16848510)
    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: (Score:3, Insightful)

      by kfg (145172)
      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: (Score:3, Insightful)

        by BadAnalogyGuy (945258)
        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 [slashdot.org]

        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 usef
      • 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.
        • 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.
    • by Osty (16825) on Wednesday November 15, 2006 @01:28AM (#16848776)

      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: (Score:2, Informative)

        by BadAnalogyGuy (945258)
        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 c
        • Re: (Score:2, Insightful)

          by chromatic (9471)

          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

          • 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

            • by rossifer (581396)

              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.

            • by dubl-u (51156) *
              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, a
          • 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 agai
        • by Osty (16825)

          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 g

        • 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 gu

          • 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 otherw
            • Re: (Score:3, Interesting)

              by Stradivarius (7490)
              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
      • 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 experie
    • by Coryoth (254751) on Wednesday November 15, 2006 @02:54AM (#16849154) Homepage Journal
      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 [wikipedia.org] 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 [inf.ethz.ch]. And yes you can have all of that for Java [iastate.edu] if Eiffel isn't to your taste (though it might be worth having a second look at Eiffel [kuro5hin.org]).

      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.
      • 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 throu
        • by Coryoth (254751)

          ...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 [secure.ucd.ie] or ES-Verify [72.14.203.104]. Of course both of

          • 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 re
    • by UPi (137083)
      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
      • 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 w
        • 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.
    • by CxDoo (918501)
      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?
      • 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 s
        • by CxDoo (918501)
          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 proces
    • 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
    • Write the test first, then write the code. You shouldn't be changing the tests to fit the code.
    • by sohp (22984)
      Are you familiar with the phrase "flip the bozo bit"?
  • What I'd Do (Score:4, Insightful)

    by hahafaha (844574) * <lgrinberg@gmail.com> on Wednesday November 15, 2006 @12:45AM (#16848528)
    > 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.
    • 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?
    • 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.
      • by hahafaha (844574) *
        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 (Score:2, Insightful)

    by MeanMF (631837)
    Make sure you give your programmers two weeks notice about the changes...Because that's probably what they'll be giving you soon afterwards.
  • 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
    • by mabinogi (74033)
      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 Mc
  • by 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 Su
    • by CxDoo (918501)
      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 (Score:2, Insightful)

    by ubergnome (242049)
    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 h
    • 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 sm

  • Try some structure (Score:1, Insightful)

    by 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 thin
  • by AKAImBatman (238306) * <akaimbatman @ g m a i l . c om> on Wednesday November 15, 2006 @01:16AM (#16848724) Homepage Journal
    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". :-/
    • Try the you break, you bought it approach. The offender becomes the new build engineer
    • by harves (122617)
      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 th
  • 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.

    • 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 programme

      • by AuMatar (183847)
        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
  • by KU_Fletch (678324) <<ude.uk> <ta> <1samohtb>> on Wednesday November 15, 2006 @01:44AM (#16848832)
    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.
    • 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 o
      • by KU_Fletch (678324)
        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.
    • by rossifer (581396)
      We use Calavista [calavista.com] 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 pe
  • by seebs (15766) on Wednesday November 15, 2006 @01:49AM (#16848860) Homepage
    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.
    • 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 de

      • by Abcd1234 (188840)
        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.
        • by thsths (31372)
          > 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 wo
          • by Abcd1234 (188840)
            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
  • 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 t
    • 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
      • by eric76 (679787)
        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.
        • 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.
  • 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.
  • Machiavelli (Score:3, Interesting)

    by Harmonious Botch (921977) * on Wednesday November 15, 2006 @02:49AM (#16849130) Homepage Journal
    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.
    • by dubl-u (51156) *
      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
  • > 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 t
    • 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 somet
      • by Omestes (471991)
        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.
        • 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.
      • by AuMatar (183847)
        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.
  • Buy some expensive (and so looking) chocolate and establish a weekly bounty for engineers who follow standards.
    • 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.
  • by mrjb (547783) on Wednesday November 15, 2006 @04:50AM (#16849596)
    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.
    • 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 k
  • 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 thin
  • Change Adoption (Score:3, Interesting)

    by KDan (90353) on Wednesday November 15, 2006 @06:55AM (#16850056) Homepage
    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
  • 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
  • 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 [isixsigma.com] 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 t
    • 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.

  • 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.
    • by thsths (31372)
      > 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 ..
  • (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 "

  • 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 to
    • The poster above is dead-on.
    • by thsths (31372)
      > 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
  • 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

We gave you an atomic bomb, what do you want, mermaids? -- I. I. Rabi to the Atomic Energy Commission

Working...