Kirill Grouchnikov's Blog

IDE lockdown - give my Java back

• at work - most probably dictated by the work-place policy (which on itself isn't bad, considering that you have to work in team environment at different computers, so you'd better have the same environment installed)
• go with the majority (hoping that the shepherd isn't blind and has no hidden agenda)
• try out various tools and see which one fits you the best

• rename (variable, member, class)
• move (class to another package)
• find declaration (of variable, member, class)
• refactor string to constant static member
• generate getters and setters for a class
• implement methods from interface
• organize imports
• reformat code

Comments

• Quite a few companies that I currently work for do not have an "IDE Requirement". I think that companies are finally starting to realize that the IDE does NOT have to be standardized for the code to be standardized.

  What I see as a current trend is for companies to instead standardize on the underlying technology. For instance one of the companies I work with requires:

  cvs
  xdoclet
  cactus/junit
  ant

  They could care less if you write in VI/Emacs or something else. The benefit of course for them is that they do not have to buy an IDE for their developers. The benefit for me is I get to walk in with my IDE and be consistently productive.

  Next time a company tells you that you MUST use a certain IDE, ask the manager (politely of course), why? As long as the coding standards are maintained (tabs/spaces, etc.) the IDE really does not matter.

  The catch is to standardize on tools that do not REQUIRE a specific IDE. Do not use a module that forces everyone to use Eclipse, JBuilder, etc. Instead choose tools that work equally well on the command line as they do inside of a tool. Then life gets easier, especially when the developer next to you is using OS X and you are using Red Hat.

  Java is all about platform independence. IDE independence and platform independence for the developer should be part of the deal.

  This response was written on a Powerbook in a 99% Windows development environment.

  Posted by: mzarra on February 03, 2005 at 01:47 PM

• I don't understand. Why don't keymaps solve this problem?

  Posted by: keithkml on February 03, 2005 at 03:35 PM

• I agree with keithkml, keymaps make this a non-issue (except if you are forced to use an inferior IDE which doesn't support a particular function which you use on a regular basis in another IDE).

  Posted by: aeden on February 03, 2005 at 06:04 PM

• Mzarra has the right idea. Although I have seen companies requiring Eclipse or JBuilder experience, I have also seen companies that don't care what IDE you use, as long as you can use CVS, etc, with that IDE.

  By the way, the next time anyone complains about using a specific IDE or coding practice/style at the demand of an employer/client, just remember how much worse it can be working somewhere that employs NO standards. Ever had to wade through 5 thousand lines of uncommented and poorly written code? I thought so.

  Posted by: sigmait on February 03, 2005 at 07:27 PM

• Many companies have highly centralised purchasing groups. These groups decide what gets purchased (ideally after consultation with the eventual users, more often based purely on salespitches from resellers) and purchase in bulk.
  As a result they get volume discounts on tools such as IDEs, which is probably the main reason to dictate specific tools in corporate environments (buy 100 copies of our IDE and you get a deployment license for our appserver free kinda deals).

  They don't then want the extra cost of purchasing yet another set of tools for the deviants who don't want to use that expensive tool they just bought in bulk.

  Many companies also have policies disallowing staff to install software of their own, so you can't bring your personal license along and use that (though smart companies do realise that providing a development group with only a standard office machine and nothing else doesn't work, sadly not all companies are that smart).

  Another reason to standardise can be training. If everyone gets an expensive training session on the use of say WSAD and then half of them go off and install JBuilder that's money wasted.

  Last but not least there's quite a few companies who don't want anything to be used that didn't pass some internal group's "security" and/or "quality" audits, processes which can take years (yes, I've seen it happen. Request a tool to be certified before you start work and get permission to use it a day before the project is due for delivery).

  Posted by: jwenting on February 04, 2005 at 12:15 AM

• mzarra,
  Suppose Bob and Alice work on the same team. Bob has his favourite Eclipse, Alice has her favourite IntelliJ. Now, Bob is stuck and needs Alice's help to debug some piece of code. She comes and starts to debug. Wanting to enter in a particular function, she happily presses F7 and, voila, she steps out of the current function instead.
  The problem here is that various members of the same team have different keymappings that work for them. It's OK as long as you are a freelancer writing yet another web framework at home. It's not OK when i come to another desktop to find out that i need to ask the fellow developer which mapping to use. Even worse, i start using mine and suddenly everything goes wrong, because my favourite Ctrl+Alt+Shift+... does something completely different in another IDE. Frustration ensues.

  Posted by: kirillcool on February 04, 2005 at 02:02 AM

• The common denominator is the command line. It should be possible to build/deploy/etc everything in a project just by running a script (Ant of course).
  Just like with email clients, etc. the best approach is to standartize the services, not the tools. If CVS (or command-line-accessible equivalent) and Ant form the basic foundation of your project, IDE choice won't matter.
  In fact, it is kind of amuzing to watch how IDE habits evolve in a group of programmers who are free to pick one. Typically you end up with approximately equal shares of Eclipse and NetBeans and a few diehards with Emacs/Vi/SlickEdit/JEdit.

  Posted by: mgarber on February 04, 2005 at 06:05 AM

• I see the problem, but the JCP is the last group I'd trust to coming up with a standard set of keybindings. A compromise has been defined as a solution that leaves everyone unhappy; I think that's the best that we could come up with here.

  The solution is good menus: Commands should not be accessible only via keyboard shortcuts (nor only by unlabeled icon buttons), and menus should be logically and intuitively laid out. That way, when Bob helps Alice on her IDE, Bob can pick an item from a menu and have it perform without surprise, even though Bob may find it faster to use keyboard shortcuts when using his own IDE.

  Like I said, I see the problem, but a standardized set of keyboard shortcuts is going to leave everybody unhappy. I don't want NetBeans shortcuts in my Eclipse, and IntelliJ uses don't want my Eclipse shortcuts.

  What I DO want, however, are keyboard shortcuts that more closely match the platform I'm using, whether its Mac OS X, Windows, or Linux. THAT can be standarized with real benefits to the users. And that's exactly the opposite of what the JCP would probably come up with.

  Posted by: jimothy on February 04, 2005 at 07:26 AM

• When upgrading to OS X 10.3, I had to remap the build and comment-section commands in armed-bear J from F9 and F11 as these became the shortcuts for Expose. Standardisation isn't a real option accross platforms.

  Posted by: pete_kirkham on February 04, 2005 at 07:45 AM

• In response to kirillcool:

  In that situation either the developer who owns the machine drives or that developer checks it into cvs and you then pull it down onto your machine for review. A third option would be to simply realize that the developer is running a different IDE than you are and (shockingly) ask him what the shortcut is.

  Standardizing on the underlying tools works in large companies. My current primary contract is with a large telecommunications company and the entire team is free to choose their own IDE. When I go to help someone I recognize that they are using a different IDE than I am and either know it (I play with most of them), ask him/her what the short cut is or move the code to my machine.

  The goal is not to have 100% efficiency since that is impossible but to achieve 80% efficiency. 80% of the time I am coding on my own on my machine using my IDE of choice. It is during that time that using my favorite way of coding will be most productive. Not the 20% of the time that I am assisting someone else or they are assisting me.

  Posted by: mzarra on February 04, 2005 at 07:58 AM

• In response to jwenting:

  Yes many companies are like that. However as I mentioned before I am seeing a growing trend of large companies moving away from the centralized purchasing schema to a more open choice. In fact the telecommunications company I am currently contracting with refuses to purchase ANY development tools. They have realized that the open source alternatives are "good enough" and let their developers choose. Each developer has the choice of using an old copy of JBuilder which was purchased previously, using an open source tool or using a tool they purchase. The same logic is holding strong on the server side as well. We are currently developing against an open source application server using open source tools.

  There is a change in the wind and the old style of purchasing 1000 licenses seems to be going out the window.

  Posted by: mzarra on February 04, 2005 at 08:03 AM

• WordPerfect has a Word-compatibility mode. Perhaps Eclipse should offer an IntelliJ-compatibility mode?

  -Jesse Wilson
  http://publicobject.com/glazedlists/

  Posted by: jessewilson on February 04, 2005 at 08:50 AM

• nice. When is Sun going to fix up NetBeans? any idea?

  Posted by: chakrayadavalli on February 04, 2005 at 01:42 PM

• mzarra, interesting development.

  I must admit I've been out of the multinational league sine 2002 but at the time the big centralised systems were very much still in place and there was a general sense that anything that wasn't labelled IBM (or name your huge corporate entity) was by definition no good.
  In fact, I worked in several multinationals where the purchase policy seemed to be a 2 step process:
  1) see if IBM makes a product. If so, buy it.
  2) is not, buy the most expensive product on the market.

  Smaler companies I was (and am now) involved with seem to have a policy to not provide anything not out of any principle to make people choose their own tools but out of either ignorance or a false believe of saving money.
  They will rather spend thousands in lost productivity (and blame it on the programmers) due to inefficient tooling than a few hundred to get the tools people need to get the job done (and by tools I don't mean just software, but also training and hardware). As an exampl: I've been fighting for a year now to get an extra stick of RAM in my workstation which would prevent Eclipse (and JB and Netbeans as well to be fair) from locking up for up to several minutes every 15 minutes or so while the OS pages data into and out of RAM. The productivity gained from not having those lockups would earn back the hundred Euro or so that that RAM costs in a few weeks at most...

  Posted by: jwenting on February 04, 2005 at 11:11 PM

• Give me jEdit and a handful of indispensable plugins and I'm happy.

  I'll use NB or Eclipse on occasion for the Java-centric browsing and profiling tools, but when it comes to cutting code I want a small fast editor and a few cool tools.

  Posted by: walkerr on February 05, 2005 at 07:40 AM

• Solution:
  I make the IDE adapt to ME!
  My first criteria for selecting one is: how easy is it to customize?
  So when I want to do something I use the shortcut.. if it does the wrong thing I go and configure it to do what I wanted. Eventually it starts behaving the way it "should"!

  Posted by: dog on February 28, 2005 at 12:24 PM

This work is licensed under a Creative Commons License.