Letting employees choose their own IDE [closed]

Question

I manage a team of developers and am evaluating the company's development standards in preparation for some new employees.

Previously the tools we used have been pretty industry standard (e.g. Visual Studio) but we are now moving into more development with open-source languages such as PHP. Since there is no standard IDE for this sort of coding, it seems I have a choice between:

• Specifying a standard IDE (e.g. Aptana, Netbeans) for all developers to use
• Allowing each developer to choose their own IDE

Which of the above options is the better one and why? If it is the former, on what criteria should I choose, because I kind of feel like I would just have to "pick one at random".

Answer 1

In my experience allowing individuals to choose their tools usually leads to better outcomes.

There are several reasons for this:

• People will use what they feel is most productive. Some prefer full blown IDEs, some prefer lightweight editors, some prefer polyglot IDEs, some prefer specialised IDEs.
• Diversity is good. If one IDE supports a great feature that significantly streamlines a process you do frequently then how will you find out about that unless someone tries it?
• Programmers tend to prefer being told what to do, not how to do it. Being allowed to control these aspects of their job will most likely improve job satisfaction.
• Tightly coupling your code-base to your IDE is generally a bad thing as it essentially becomes an extra tightly coupled dependency to maintain. IDEs are also not immune to bugs, being discontinued or being superseded by superior products.

However, to make this work:

• Your build/deployment process/tools should be independent of your IDE. Therefore you should be able to build your code-base with any IDE or without one at all. Leverage tools like Gradle, make or phing rather than inbuilt IDE tools (most IDEs integrate with these external tools any way, but if not developers can use command line instead).
• You should ensure that you have consistent and portable standards for things which are usually delegated to the IDE, such as code formatting. Most IDEs have some form of portable configuration file for code formatting, so ideally you would make consistent code formatting configuration files available for several common IDEs.
• Barriers to adopting a preferred IDE should be minimised, for example by creating a process/policy where developers can request licenses to be purchased on request (assuming the software has been trialled, etc. first)

Answer 2

Focus your attention on the quality of the code and let your developers decide how they will achieve it. They'll feel more empowered and responsible for their productivity. If for whatever reason, an IDE choice creates problems with the code, you may have to put restrictions in place.

It's bad enough when you have to implement/defend corporate-wide limitations (annual review) on your team members, so don't go out of your way to create more. Good craftsman make good tool choices. Coding is not an assembly line process.

Again, only fix problems when they become problems.

Answer 3

Per request the other side of the argument from @thexacre's answer.

IDEs strengths and weaknesses

So you go with multiple IDEs as no IDE is perfect and you devs each are more effective in their choice IDE. You now have people developing in PHP Storm, Notepad ++, Joes PHP IDE. As mentioned each of these applications have their strengths and weaknesses, and in some cases will create a nice synergy where when one IDE falls short, the other one picks up the slack...

Unfortunately that's a bit optimistic just as often as one IDE's strength will overcome another's weakness an IDE will introduce a weakness that wouldn't otherwise be there. For example PHP storm when your write a database call it uses a really efficient method of doing so by default, but Joe's PHP IDE really lacks in this area... If something is written in Joe's PHP IDE opening it in PHP Storm won't rewrite it. This means by using Joe's PHP IDE your application now has it's weaknesses in addition to PHP Storms!

Code standard woes

In even the most rigidly structured languages code standards become hot issues where certain things just never mesh. Now you move to code that's open source where these standards become far more lax. Luckily IDEs often help us adhere to some level of standard if for no other reason than the IDE defaults to it.

Now enter multiple IDES... Let's say PHP Storm organizes your code in a certain manner. As long as you stay true to this structure and/or use only PHP Storm navigating your code is easy! new we introduce multiple IDEs... Each has their own nuances on how they like to structure things. How are my conditions formatted? perhaps PHP Storm likes to put backend code into one place, while Joe's PHP IDE likes to put them in another.

Very quickly this can turn clean elegant code into the stuff nightmares are made of. Where every time you go to look for something you need either already know where it is, or you have to start going step by step to figure out where on earth it lives. Or you have 3 places to check for one thing... IE it's TERRIBLE!!! You can enforce this by being mindful, but expect to start that battle over every time you hire someone new on.

Formatting woes

Tabs or spaces? (is but the beginning) Every IDE has it's own preferences on how code should be formatted. Some of these minor differences are extremely mild, others will bring about near holy war dispute among peers. In some cases the IDE won't even give you a choice it'll just reformat everything based on how it believes is correct.

Having the gap on an indent vary between 3 and 4 spaces is only the beginning. These things can change how you structure your code, when new lines start, whether you use single quotes or double quotes, etc. This stuff won't break code, but could break moral is developers are continuously faced with code formatting that changes hourly.

Source Control and Build Servers

In many cases most modern IDEs will play nice with any big name source control and build server solution. Though some will require plugins, addons, extensions, whatever...

However, if you are NOT using big name tools you might be treading into dangerous waters. PHP Storm might not support the solution you've chosen, or perhaps not well... But maybe that solution is excellent on Joe's PHP IDE... Do you now change tools to something that's not as suited for your needs to make sure both IDEs support it?

Terminology

There are certain things terminology wise that are pretty universal in code. What is a method, class, etc. There are other things terminology varies. While most of the terminology should be the same confusion might come to pass where in one IDE a word refers to something that means something totally different in another IDE.

For example in one IDE "Addon" refers to additional functionality to allow use of third party tools, while in another IDE it's simply extending the functionality already in the IDE itself. (Like accessing a build server vs turning on unit testing)

Admittedly this isn't a huge issue, but it's something else to consider.

Summary

There are valid arguments on both sides. Ultimately you're choosing between the effectiveness of the individual vs the team. If everyone is 20% more effective using the IDE of your choice at the cost of only 10% effectiveness of the team using their own IDEs is a win! on the other hand if each individual is only 10% more effective at a 20% cost to the team then choosing one IDE is likely better.

And where your company falls depends on the culture, the work, the individuals, etc. It's something any metric you pull will be somewhat subjective or flawed, but you might be able to get a reasonably guess.

My gut feeling would be if there is a lot of pair programming or multiple people working on the same part of the application you're probably better off with just one IDE. If for the most part the devs work on separate things and mostly just come together at the end to merge or reference code allowing the devs to use their own IDEs might be better.