Where I work we have a number of teams that are converting over to having a team dev environment. Basically a couple members of the team are putting together an image that is then installed on everyones computer. It includes an OS, an IDE (with source control managed from it), a couple of server systems they need for testing and a test server image. Ostensibly the imagine is being compiled based on everyones input, so everyone is, again, ostensibly, happy with the environment in question.

The team leaders claim that this will be more efficient because whenever anyone has a problem everyone else on the team can help fix it (as opposed to, say, the other 2 who are still using vim.) But, at the same time, it seems like this approach would have a negative effect on people who don't excel at working in the majorities paradigm.

So my question is this: is the trade off worthwhile? Are the "team support" gains likely to overcome the "individual efficiency" loses? Tangentially, is there a halfway point? Perhaps if everyone had the same OS and the same server image but were allowed different IDEs, that might be better?

  • I realize this question isn't technical so it's a bit open to interpretation, but I assume there are people who have experience in this sort of situation who have valid input? I'm not so much looking for opinion as feedback.
    – Jae Carr
    Apr 24, 2014 at 13:12
  • 1
    "This site is all tour getting answers. It's not a discussion forum..."
    – gnat
    Apr 24, 2014 at 13:16
  • And I'm not interested in a discussion, I'm interested in facts from people who have been in the situation before.
    – Jae Carr
    Apr 24, 2014 at 13:19
  • 1
    your dev team use different OS's ? what and why ? Apr 24, 2014 at 13:20

1 Answer 1


Where i work we use the same policy - one main image, that is installed on all development computers (in our case windows, visual studio with plugins like R#, ghost doc, editors, regex tools, and so on).

I don't think anyone of our team members has ever experienced any drawbacks regrading the image policy, quite the contrary:

  • we have the same directory structure for our project mappings, so local references in source codes are always the same
  • we have the same applications settings
  • we have same key mappings, so changing workplaces (if needed or for example to do pair programming) won't affect our productivity
  • changing the hardware won't be a breaking change to any dev member
  • if someone needs help, for example extending a regular expression - the regex per email will suffice, everyone has the same tool for testing
  • same (product) updates apply on every machine / machines are in sync
  • this also means same behaviour on all machines (how nice if this would have been true :-)

On the other side, we can always adjust / extends some settings resp. add new software locally

  • for example i have added my own R# keymappings
  • i was for a long time (about 1 year or so) the only one using/having LINQPad

IMO we have a great benefit from that policy and i don't see how this approach would have a negative effect on people who don't excel at working in the majorities paradigm.

At the moment we have two trainees that started about 6 months ago. Since for them everything is new, learning the same tools and shortcuts that we use is not a bad habit. One day (after they know how everything works and can be set) they can always decide to define their own settings and / or try new and different tools.

The individual efficiency loss can be IMO neglected - the same image policy can be compared IMO with the coding guidelines - the team is more efficient, when everyone has the same style and also everyone adapts a bit. It is after all also a continuous learning process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.