Getting Development Group To Adopt New Practices? 125
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."
You don't ship test code (Score:4, Insightful)
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)
How do you get management not to implement a new standard or 'best practice.'
KFG
Re: (Score:3, Insightful)
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
Re: (Score:2)
Of course, it's often one of your own "control-freak" team members that give management the idea in the first place.
Re: (Score:2)
Re: (Score:1)
KFG
Re:You don't ship test code (Score:5, Insightful)
Code without tests is not shippable 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.
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)
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)
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
Test-driven development (Score:3, Interesting)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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 platform
Re: (Score:1)
Re: (Score:1)
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
Re: (Score:2)
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
Re: (Score:1)
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)
Besides, the developer
Re: (Score:1)
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
Re: (Score:2)
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.
Re:You don't ship test code (Score:4, Insightful)
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.
Re: (Score:1)
That is different from unit testing which seeks to build a wrapper around units of code in order to put the code throu
Re: (Score:2)
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
Re: (Score:1)
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
Re: (Score:1)
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
Re: (Score:1)
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
Re: (Score:1)
Re: (Score:1)
I didn't get this; you are suggesting to get rid of realistic people in order to introduce standards-compliant practices?
Re: (Score:1)
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
Re: (Score:1)
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
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:2)
Re:You don't ship test code (Score:5, Insightful)
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: (Score:1)
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 str
Re: (Score:1)
I like
Re: (Score:2)
Re: (Score:1)
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.
Unit testing is good, but not everything (Score:2)
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 la
Re: (Score:2)
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 o
Re: (Score:2)
I think you're conflating two kinds of testing. To me, unit tests prove that the code does what the developers think it should
Re: (Score:1)
I'm not advocating this particular methodology, but there are people who would disagree with you.
http://www.literateprogramming.com/ [literateprogramming.com]
Re: (Score:2, Insightful)
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
What I'd Do (Score:4, Insightful)
Adopt the new practicer. Or you're fired.
Send out memos (Score:2)
Did you get the memo?
Boss #2 (Score:1)
Re: (Score:2)
Re: (Score:2)
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)
There's the old stand by... (Score:2)
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
Re: (Score:1)
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
Incremental change. (Score:1, Insightful)
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
Re: (Score:1)
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)
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
Re: (Score:2)
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)
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
Beat 'em over the head (Score:5, Interesting)
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: builds (Score:1)
Re: (Score:2)
One thing I would also suggest is that, whoever becomes the maintainer for your team gets to set th
Tangible business value (Score:2)
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: (Score:1)
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
Re: (Score:2)
Re: (Score:2)
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.
Performance tracking with bonuses (Score:4, Interesting)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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
Maybe involve them? (Score:4, Insightful)
Developers must experience a benefit (Score:2)
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
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
IMHO, development practices should be
Tell them why it's important (Score:2)
Re: (Score:1)
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
Re: (Score:2)
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: (Score:1)
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 best best practice (Score:2)
Machiavelli (Score:3, Interesting)
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: (Score:2)
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
Get them involved (Score:2)
> 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
Give them inscentives. (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
My opinion (Score:2)
Re: (Score:2)
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 (Score:3, Insightful)
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: (Score:1)
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
This is Simple! Three Easy Steps (Score:2)
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)
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 (Score:2)
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
Try the Six Sigma approach (Score:2)
Many organizations (including my own) are guilty of making changes to process and procedures without fully involving t
Re: (Score:2)
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" (Score:2)
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.
Re: (Score:2)
"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
Peer review (Score:2)
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 "
You're doing it wrong (Score:2)
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
Mod parent up! (Score:2)
Re: (Score:2)
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... (Score:2)
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