[brown9-2]

But there is a huge difference between enforcing style rules and enforcing which editors people use.

You can have different team members using different editors, but with the same style rules - and with a style checker that runs on commit/post-edit to verify the common rules are adhered to.

Enforcing which editors each team member must use to do his/her development is a form of management deciding it knows which tools each developer will be more efficient with than the developer does. It's pointless.

[nraynaud]

no, I can't, because I don't want to configure the IDE and then the style checker. And the the commit is rejected where it shouldn't have been because it could have been well formatted from the beginning and nobody cares about that because the editor does it for us (it's not totally true, since it doesn't remove useless endlines)

As far as I know different editors can't be made to produce the exact same code on automatic reformatting. And enforcing code style still doesn't help people switching keyboard, reading code or stuff like that. It's a team I'm building, not managing insulated people.

I enforce that everybody uses the same editor, if I find myself in a team where the majority votes for emacs, they'll just use emacs (and I guess I'll resign). Our last change was initiated by a team member.

[brown9-2]

Why so you need to configure someone else's IDE? Just produce a style checker ruleset (like Checkstyle) and tell team members they can use a non-standard editor if they want, but that any output that doesn't match the style checker will be rejected.

It seems to me that if you never allow anyone to use a different editor than you close your team off to the possibility of finding improved toolsets or workflows.

[nraynaud]

I don't prevent people from trying stuff, I just don't ant them to keep with a different IDE. They try it for a while, after that either we try it with the rest of the team an decide to adopt it all together or we reject it.

I don't know what is the problem. We just adopted New Relic with this method, removing pingdom + a bunch of custom stuff after someone proposed it, tried it, extended the perimeter of the trial and then it was good to go. We delete the other stuff, and it's our new common tool.

We did the same with our deployment scripts, where a guy started in his corner, but after a while we decided to go whith it and now it's out of question to use any other way to deploy an instance unless we do a collective decision to change.

Concerning the workflow, one guy tried a new testing tool, it appeared good, we now use it. That's it, everybody uses the smae testing framework, the same monitoring tool, the same IDE, the same deployment system. And they can do trial on the side, we'll extend the trial if the first guy testing the tool thinks it's a good stuff for the team and then we'll decide together to adopt it or not. Mostly if the tool is not deemed good the first time, the others won't really ear about it, and if it's good and the extended trial is good, I'll ask we delete something else if possible, try to "trade" one tool/library for another and limiting the entropy.