80

I recently joined a rapidly growing startup. In the past 3 months the development team has grown from 4 to 12. Until now they were very laissez-faire about what developers used to do their work. In fact one of the things I initially found attractive about the company is that most programmers used Linux, or whatever OS they felt best suited their efforts.

Now orders, without discussion, have come down that everyone is to switch to Eclipse. A fine editor. I prefer SublimeText2, but it's just my personal taste.

Just to be clear: we are a JS team using Backbone and Eclipse just isn't good at understanding Backbone code. This means that those on the team who use a /good/ IDE (PHP Storm), have to go back to doing a lot of search-find-oh-wait-where-was-I-three-steps-ago kind of things instead of just ctrl+clicking and using back/ forward - probably diminishing productivity by say 15% and enjoyment by 50%...

Is this a red flag? It seems capricious and unreasonably controlling to tell developers (non-MS) what IDE or tool-sets to use if they are already settled in and productive.

Improve this question
19
  • 7
    What is your build process? What needs to be in place for the characters you type to become binary code to go to customers.
    – user1249
    Mar 18, 2012 at 14:54
  • 23
    This is a start-up. If management unilaterally makes a decision like affecting development, without discussion, it could be a major red flag regardless of what it's about.
    – joshin4colours
    Mar 18, 2012 at 15:54
  • 29
    No - there are a myriad of reasons for going to a single IDE: licensing, process, continuity, consistency...
    – Wonko the Sane
    Mar 18, 2012 at 16:12
  • 55
    A growing company trying to establish a standard early on is a smart one in my book (no matter what it is)! Put everybody on the same page and build up expertise with a common IDE. Then the team becomes more efficient because everyone can help each other, and can share code more easily without having to worry about tab space width, encoding and things like that.
    – Yanick Girouard
    Mar 18, 2012 at 22:55
  • 23
    Eclipse is a whole environment, not just an editor. Maybe IT found that dealing with every special snowflake at a growing company was becoming a huge and onerous task and wanted to standardize. Maybe there's a tool in the Eclipse ecosystem management want to use soon. Maybe 12 different auto-formatting editors was pissing off your repository and causing extra builds. Possibly unlicensed tools "from home" worry management who don't want to get sued. Maybe you're the new guy, do you really expect to be consulted on broad IT and development decisions? Could be a million reasons, all sane.
    – Patrick Hughes
    Mar 18, 2012 at 22:56

20 Answers 20

Reset to default
92

"Now orders, without discussion, have come down that everyone is to switch to Eclipse."

I think that this is the real red flag. Your team is the expert on software development and the one to be affected by the decision, and yet you did not get to say a word in the discussion that resulted in this order?

It sounds like over-managing by pointy-haired bosses. Does the decision making person/team have relevant insight for that decision?

Given that the decision makers are qualified enough for such a decision, not asking for the dev team's opinion has at least two shortcomings:

  • The team does not feel involved. Involving the team should be a priority for management. I would not like to work as a dev somewhere where my opinion about such central issues as IDE is not valued enough to even be asked for. Granted that asking for someone's opinion and then deciding against it may be worse, but in that case I'd expect a solid rationale for that decision.

  • The management, however experienced, does not work 100% with development of this specific code. Assuming that the people who do don't have interesting insight at all would be naïve. Of course it may be so that the managers had thought of everything the devs come up with, but the only way to know is to ask.

Improve this answer
11
  • 9
    Nonsense. Just because the team wasn't consulted doesn't mean the higher ups are clueless. Its interesting as a non-Java developer, I know Eclipse is the IDE to use pretty much, but never heard of the OPs favorite until he posted it. It would be a mistake to allow the team to standardize on an IDE that's uncommon, creating problems with recruiting other new developers.
    – Andy
    Mar 19, 2012 at 1:53
  • 5
    Have you considered that the "upper management" may be senior developers? Some organizations have many layers?
    – user1249
    Mar 19, 2012 at 13:08
  • 2
    You're reading way too much into this. Management may have other concerns, like support options, and it may have come down to something that was fairly popular with a reasonable support cost (I'm talking about paid support incidents). If that's the case, there may have been no other choice, so what would be the sense in asking the developers? Also, have you tried to get even a small number (10-15) of developers to agree on something? There's a reason they say getting developers to agree is like hoarding cats.
    – Andy
    Mar 19, 2012 at 16:27
  • 3
    @Andy Hoarding cats is easy (speak to any spinster), hearding them is another matter entirely. ;o)
    – JW01
    Mar 20, 2012 at 21:26
  • 3
    @JW01 Ahh, I got the wrong word. But wouldn't it be herding? :-)
    – Andy
    Mar 20, 2012 at 22:04
63

It is reasonable that when you working together on a common project, that on every workstation you have all the tools available to edit/build/debug your software, and that the core tools for doing about 90% of the development are known to everyone in the team. That goal is harder to achieve if your team is growing and everyone uses his personal favorite toolset - the more people, the more opinions. And the administrative work gets easier, too, if you don't let the number of tools grow more than necessary.

Of course, if one developer insists to use his personal favorite editor, that may be ok as long as he can make sure the source does not look or behave differently in the main editor of the team (in your case Eclipse), so if dev B has to to edit the source of dev A, dev B should not be forced to learn the personal favorite editor of A to be able to change the source effectively. But beware, if the two have to work together from time to time in front of the same display (or do some pair programming), things are often easier if the choosen editor is well-known by both.

Improve this answer
9
  • 3
    First of all, it's rare that a developer has to make changes on someone else's machine. I agree with "the more people, the more opinions", but that's not a problem unless people try to impose opinions on others. Re the source, all projects should have an automatic one-command build process. As long as that works, and the code follows conventions, it doesn't matter which IDE people are using. Most IDEs are intuitive for simple things (they each have their own benefits for more complex tasks), so pair programming isn't a problem. If there are questions, the developer using the IDE can answer.
    – Matthew Flaschen
    Mar 19, 2012 at 1:31
  • If you both know the language, looking at a different editor really isn't a problem. Some syntax is highlighted differently and the filename may be in a different place, but there's no problem unless you're actually using another developer's setup.
    – Izkata
    Mar 19, 2012 at 2:32
  • 32
    I work at google and in my particular team one person uses Eclipse on person uses intellij I use Emacs with evil mode to emulate Vim and one person uses Vim itself. We work fine with each other and the tool differences are no problem. It does help that we all use the same build system and have a set style guide for reading code but that has little to do with the editor choice for each individual.
    – Jeremy Wall
    Mar 19, 2012 at 3:01
  • @JeremyWall: as I said, it may be ok, if your source code is displayed equally in all editors you are using and you don't do much pair programming.
    – Doc Brown
    Mar 19, 2012 at 12:39
  • 5
    @JeremyWall : Just because your team of developers can work like that, does not mean that all teams can work that way, and in fact, I'd consider a team of Google developers to be outside the norm.
    – James P. Wright
    Mar 19, 2012 at 18:35
25

For pair programming sake, it's nice if both parties infront of the screen has the same skills when using the keyboard. It's also nice to know that, if your project has special configuration needs in the IDE, then It's configured the same way for everybody. Getting a new developer started is easier when the tools are the same for everyone.

But if you compare that to just trying to be most effective, then it's not really worth it

Improve this answer
3
  • 7
    +1 for noting benefit of similar development environments when pair programming
    – jcmeloni
    Mar 18, 2012 at 14:19
  • 1
    +1. I couldn't agree more. Working with multiple developers each having their own preferred tools and ways of coding can be hell! For example, you may want to enforce space over tabs, a specific indent size, and UTF-8 encoding for all your sources. I had to go through this in my team before and we had to have everyone use the same IDE in the end exactly for the reasons mentioned above. Any serious developer wouldn't have to spend long to adapt to a new IDE anyway, so I don't see the harm in it. It also makes it way easier for new members to get up to speed if everyone uses the same tool.
    – Yanick Girouard
    Mar 18, 2012 at 22:51
  • @Yanick: Space over tabs, indent size, encoding... All these kind of parameters must live in the coding standard, which all developers must comply with. It does not matter how they want to comply with them, does it? Formatting requirements should focus on the result being correct, not on how to get there. If the devs need to switch IDE to get the correct formatting, then I wouldn't call them "serious developers", sorry for being bold.
    – Gauthier
    Mar 19, 2012 at 14:34
18

Yes, it's a bit of a red flag that management considers itself a better judge of which tools you would be more efficient with than you are.

Improve this answer
20
  • 38
    Strongly depends on the reasons WHY the IDE should be the same.
    – user1249
    Mar 18, 2012 at 14:53
  • 3
    We are not sure from the question who made the decision or why. The term "without discussion" could mean that they didn't include the new guy.
    – mhoran_psprep
    Mar 18, 2012 at 15:49
  • 3
    I don't have the rep to downvote, but I disagree this perspective. Even if the tool decreed by management were in fact not the best, it would be better than having no standardisation. Clearly the devs aren't capable of taking the decision about which is "best", since left to their own devices they've all chosen different tools. It's fatuous to claim different tools work better in different contexts, since most of those devs won't actually become fluent in very many anyway.
    – FumbleFingers
    Mar 19, 2012 at 1:25
  • 4
    "Clearly the devs aren't capable of taking the decision about which is "best", since left to their own devices they've all chosen different tools" They're choosing the best (most productive) tool for themselves. Everyone has different experience and work patterns. They can all be right.
    – Matthew Flaschen
    Mar 19, 2012 at 1:32
  • 2
    @Andy Thats' not actually true, as the disagreements of Vim vs Emacs show. And those are primarily text editors, not full IDEs. It can take years to get up to speed in a new environment.
    – Izkata
    Mar 19, 2012 at 2:35
14

It's not a red flag in itself.

Sometimes management need to take decisions. Any issues that require standardisation on something tend to fall into that category. I once worked at a client who had allowed standards to drift for a few years and they had 20+ different SCM tools. What started as independent choice by different development teams turned into a logistical nightmare that severely hampered sharing of skills and collaboration on code across the organisation. Integrated build were..... er..... not very integrated.....

Furthermore, it's not practical or necessary to consult everyone for every decision. The extent to which this needs to be done depends on the culture of the organisation and the importance / complexity of the decision. Typically you'd take one of these less consultation-heavy options:

  1. Make the decision yourself, if you have sufficient knowledge of the pros/cons and it's not an important enough decision to require wide consultation.
  2. Consult with a few key individuals (who would probably be the senior developers most qualified to take the decision).
  3. Raise the fact that you are making a decision to everyone who might be affected (email, town hall meeting, team meetings). Say what you think the right decision is but that you're willing to change this if new evidence emerges to the contrary. Invite people to come forward individually if they have some important views
  4. Invite people to form a sub-team to review options and recommend a decision. Good option if it is genuinely a close call, you don't know the answer and you want those involved to be bought into the decision.

For something like developer tooling (which is a potentially contentious issue) I'd probably do 2 followed by either 3 or 4. i.e. there would definitely be some individuals I wouldn't talk to personally on the issue, but on the other hand most of the key people would get a chance to contribute to the decision making.

To me the real red flag would be around if you feel strongly that the wrong decision has been taken (wrong == it harms the company rather than just your favourite tool wan't chosen). How does management react when you raise this issue:

  • Good management will listen to your argument, thank you sincerely for the feedback and reconsider their position in the event that you have raised new insights. They may still not agree with you and may stick to their decision, but they will appreciate that you have raised it with them and do you the courtesy of saying why they are sticking with their decision. They might even change the way they make such decisions in the future, and if you made good points may include you on their list of "smart people to ask".
  • Bad management will get defensive, say that "the decision is made" and other such tactics to avoid facing the fact that they may have made a wrong decision. They may see you as a "troublemaker". The company suffers, as does your faith in management. This is a real red flag! Get out while you can!
Improve this answer
7
  • 6
    There is a pretty big difference from an ide/editor and an scm or build system. and ide/editor is for personal use and usually tailored to the individual. The scm or build system is used globally by everyone. One of these things needs centralized management the other most definitely does not.
    – Jeremy Wall
    Mar 19, 2012 at 3:05
  • 2
    My answer was targeted at the management issues rather than the specific decision on IDEs per se. However there are also many good reasons to standardise on an IDE (e.g. skills, training, licensing costs, pair programming efficiency, integration with other tools, overall quality of IDE, support costs, deployment ease). In some contexts the right decision will be to standardise - you are incorrect if you think this can always be left to individual choice (even if this is the right decision in many situation)
    – mikera
    Mar 19, 2012 at 3:09
  • 2
    @Jeremy: I think your perspective is perfectly fine for a one-man-band or a small group of hackers. I sympathise strongly: I'm exactly the same for my own personal projects. But that approach simply doesn't scale to larger enterprise contexts. Having a preference for tools is fine, but I expect a good professional developer to be willing and able to learn and adopt whatever tools make the organisation most effective as a whole.
    – mikera
    Mar 19, 2012 at 3:51
  • 3
    My perspective is shared by my employer Google who certainly qualifies as a larger enterprise context. I agree that a good professional developer should be willing to learn and adopt tools to make the organization most effective as a whole. I disagree that an ide or editor could ever fall into that category.
    – Jeremy Wall
    Mar 19, 2012 at 3:55
  • 2
    Cool, great company and you're lucky to work in a place that is able to operate as lots of "small groups of hackers" on relatively independent projects. Most big enterprises don't have that luxury, sadly. Think big bank that needs to hire and train 100 entry-level Java coders in India to work on maintaining call centre apps. Encouraging them all to be creative and choose their own IDE/build workflow is simply not going to work.
    – mikera
    Mar 19, 2012 at 4:32
12

If you are using maven or something similar, it shouldn't matter which IDE you are using. There might be cases where one is tied to a specific IDE like eclipse, if there are plugins you rely on.

I think you should be able to choose your own IDE, the IDE you are most productive in. However, as I already stated there are cases where it makes sense to use a standard IDE.

Improve this answer
1
  • eg. if you want to do ADF, then JDeveloper is the natural choice, plugins for other ides may not have all the functionality.
    – Rohit Banga
    Mar 18, 2012 at 15:20
12

Every team I've ever been on has had a multiplicity of IDE and editors: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine -- it's never been an issue. Never.

To me this speaks to a misunderstanding at the high levels of the organization, as to what really matters. What matters is letting good coders do what they need to do and use the tools that make them most comfortable. IDE uniformity has very little to do with the real communication that takes place about the essential questions of object architecture, unit testing, algorithms, etc.

Having the same IDE as the next guy just means that we both know how to browse the code with the same shortcuts, and how our compilation/configuration is set up. None of which will matter when talking about real code issues.

Look, it's livable, depending on other factors at the company. You can always use your own preferred editor for day-to-day stuff. And maybe your group is doing other great things that creates great culture. But mandated IDEs is a huge misstep IMO. For me, if I were interviewing with a company and they informed me which IDE I was allowed to use, I would thank them politely for their time.

Improve this answer
11

I'd have the "corporate mandated" IDE installed, but would still do most of my work in whatever IDE I wanted--it's not like anybody can tell what IDE was used to edit a source file.

On the IDE vs. editor front... for almost all languages, I strongly prefer an IDE (IntelliJ) because there's just so much more it can do for you than an editor can. There are some things I revert to ST2 or Emacs for, but for day-to-day coding, despite how much I like both ST2/Emacs, the IDE almost always wins.

Improve this answer
3
  • 1
    I dispute your assertion that an IDE can do significantly more than an editor. There are clearly inferior editors , e.g. you wouldn't do serious development with nano or gedit, but I can code faster in vim than I, and I would guess most others, can in an IDE. And though I hate to defend emacs, I'm sure an experienced emacs user is faster in emacs than an IDE as well.
    – Kevin
    Mar 18, 2012 at 18:35
  • 1
    @Kevin Dispute away--I'm a long-time Emacs user, and getting better with ST2, and there's simply no comparison. Better, more-context-sensitive completion, tighter debugging integration, there aren't too many things for which I'd give the nod to a text editor. Some languages fare better than others, for example, I wouldn't code Java in Emacs pretty much no matter what, for Ruby and Python I'm about half-and-half, but IntelliJ is winning me over. For actual text editing, whether it's code or not, I use an editor.
    – Dave Newton
    Mar 18, 2012 at 18:56
  • 1
    I know the question and most responses are geared towards the Java world, but over here in Microsoft's .NET world, the idea that an editor could be better than the mainstream IDE (Visual Studio) is absolutely retarded. I would not hire a .NET dev who insisted on using Notepad++ over Visual Studio.
    – Graham
    Mar 20, 2012 at 13:40
8

In our Ruby shop there's a strong recommendation to use the IDE most of the team enjoys (RubyMine), because we know it does the job and we can teach each other shortcuts etc.

Developers are free to use a different IDE, but we require them to have solid skills in that editor should they choose so. If we see someone struggling to navigate their project or edit text in their custom FooEdit, RubyMine for them it is.

Improve this answer
5

If a programmer is an expert at a given IDE, then they should use it. If they aren't an expert at any IDE, there's probably one or two that are very common for your programming language, or within your team, and it probably makes sense for them to learn it.

Being forced to standardize on an IDE sounds like a terrible idea.

Improve this answer
3

This is a massive red flag. Every company has a few such stupid ideas, but if other red flags keep coming, just leave.

Improve this answer
1
  • Disagree. Many great companies make decisions fast, and if they make a mistake then listen to feedback and iterate. They don't waste time getting bogged down in endless consultations for every decision.
    – mikera
    Mar 19, 2012 at 2:00
2

The reasons for a company to force a particular editor or software in general on their developers should be examined. The paranoid (maybe not the word I am looking for) part of me thinks there might be some sort of productivity tracking added to the eclipse they are asking developers to install. A much less paranoid (again) thought would be that they have spent time adding product build tools to this IDE that would make things much easier if everyone pressed the same button to test and build their code branch.

Anyway what I am trying to say is its probably more than just mere bureaucracy, or a method of messing with the developers heads.

Improve this answer
2

It is easy for the motivation behind some decisions to get lost - especially with rapidly growing team. The motivation to move to Eclipse might just be the fact that most of the developers seem to be wasting a lot of time just configuring the IDE and that there is only limited expertise withing your company.

I would just take the order to move to Eclipse to mean that you should have Eclipse setup in case it is needed, but continue your work in your favorite editor. (You might have to move to Eclipse gradually if your company starts deploying cool tools within Eclipse.)

Red Flag: I would wait if there are a few more such irrational orders before being worried.

Improve this answer
1

A startup is generally trying to stay agile long enough to figure out a sustainable business model. Once it figures out the money part, management moves in to scale up the business. That's generally when all the early tech employees start leaving, as engineering processes gets tightened up.

As you know, you don't know what code will actually do until you run it. Turing proved that in the early days of computing. This means that there is no such thing as any meaningful measure of productivity when it comes to writing software. However, for management to do its job, productivity must be legible. Since you can't measure code (and people have tried -- lines of code, for example), they will measure what they can see. Programmers are more legible than the software they develop. The typical management team attempts to control programmers in order to make these things legible to them (instead of doing their real jobs: getting out of the way). And because they measure the wrong things, it doesn't work very well.

Having said that, you can still go a long way with a loosely-coupled team. Github's development team has around 50 people and they break every rule in the business management textbooks. They seem to be doing all right. Bugs get fixed (eventually). Features get added. Fires get put out.

What is a big red flag is if they are trying to scale things up without having figured out how to make money. At that point, you got to wonder how much of your unvested options and grants are really worth.

Improve this answer
2
  • This seems completely unrelated to the question. Did you mean to post elsewhere?
    – Daenyth
    Mar 18, 2012 at 16:34
  • @Daenyth I mean to post this here. The original headline "One IDE to rule them all?" had nothing to do with the explanatory paragraph. The OP seems to be asking if being forced to use an IDE indicates time to bail from the company.
    – Ho-Sheng Hsiao
    Mar 19, 2012 at 19:11
1

Surely this is a bad idea. It is inevitable that the team will become less productive since they have to learn to use new tools. And even then they won't be as effective as with the tools they already grok.

Since I've tried various tools myself I always had at some point that feeling "gosh, this editor is annoying me with <insert some bug/difference from prefered tool>". So it'll be a moral drawback as well.

But of course there are also pros to have a whole team use the same tools. Sharing configs, skripts, plugins and all that sort of stuff. Which wouldn't be possible with a diversity of toolsets.

On the other hand… that last bit wouldn't be necessary if everyone used his or her preferred software. ;)

Improve this answer
0

You can "use" Eclipse while still typing in SublimeText2.

This means having Eclipse installed and configured for your projects and getting up to speed with it so that you are equally comfortable using it if, say, pair programming. Nobody will (or at least should) care what editor you actually used to type in a piece of code you committed as long as maintaining your parallel setup doesn't take up an undue amount of time and you don't cut yourself off from the standard development environment.

Improve this answer
0

If you're using Git and your branching is down, you shouldn't need to be using each other's editors anyway. You can just push a branch and have another dev pull it to get it working if he really can't figure your toolset out. Forcing everyone to use the same editor sounds like an order by some business head who wants to look smart but doesn't really understand the way you guys operate.

Improve this answer
0

If you think about this from a management point of view, the reason they may be doing this is for legal compliance. The company is responsible to ensure that every tool used is being used legally and will also not encumber the product that is being developed. (Some editors are free for personal use, but not free for any other purposes, etc.) To audit every tool that every developer may want to use can be expensive. I've seen that on projects where time lines are tight, management will be cautious about which tools/libraries/etc are used to minimize changes later in the project that are directed by the legal folks.

On higher security projects there is also the concern of where the IDEs store temporary files, and what information is stored between sessions.

Improve this answer
0

It all depends on the reasons they have to recommend Eclipse. If developers are having trouble setting up their environments because everyone organizes things differently, there may be a reason to recommend a straightjacket. If, however, everybody was happy and productive using whatever they wanted, there is little reason to impose a change on something so deeply involved in the creative process.

Eclipse is a lot more than an editor - you may keep using your favorite editor for editing your code and rely on Eclipse for source control, debugging and whatever else the corporate mandated workflow wants it used for.

One final thing - enforcing process in this level may indicate the company intends to expand the development team and wants to have a certain bit of structure in place so new teammates can get productive faster. If you think Rails (or Django) as an "opinionated" framework, you'll realize having structure helps to understand new applications easier.

Improve this answer
0

The red flag is not so much that a single IDE/editor is being forced upon every developer, but that this decision, and especially the decision on which IDE/editor was to be used was not made by all the developers, and perhaps none of them!?!

Certainly it would be best for the developers to reach a consensus, especially because they are obviously best qualified for the decision (at least on which editor/IDE). There may be good reason to conform and that decision should weigh-in the preference of management, but which editor/IDE should have been the decision of all the developers.

Getting 12 developers to cast some votes would be easy. Certainly there was time enough to do that! The conclusion would have been painful for some anyways and it might have even ended up being Eclipse in the end, but labeling the requirement as a "red flag" in that case would be much more debatable.

Improve this answer

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