Is a company order to switch to a certain IDE a red flag?

Question

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.

Answer 1

"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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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!

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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

Answer 12

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.

Answer 13

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.

Answer 14

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. ;)

Answer 15

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.

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

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.