Jeremy French

My Site, still on Jekyll, now powered by github pages

27 April 2010

Putting the 'I' in IDE

by Jeremy French

Developers often get het up about their editor, as it has been and probably always will be. It is a very personal choice. As it is the system you will spend untold hours interacting with.

I am not going to say there is a right or wrong system. My preference is eclipse however my reason for linking it is not in any particular shortcut or way of working. My reason for liking it is that it is integrated

There are various tasks involved in development. There is of course the coding. However there is also debugging, version control, bug tracking and often time tracking. The more tightly integrated you get all of these, the less context switching you will have to do and the more effective you will be as a developer.

To illustrate this I will take an example with a fictitious un integrated system for fixing a trivial bug.

  1. Open bug tracking software and find bug assigned to you and read it.
  2. Open editor and fix trivial bug.
  3. Build software in software building tool
  4. Test software in software environment.
  5. Open bug tracking software again to get reference to bug.
  6. Open source control software to commit bug.
  7. Open bug tracking software to mark bug as resolved

That is a lot of context switching. Compare to example with fictitious ultimate integrated environment.

  1. Open next task in UIE
  2. Fix bug
  3. Click on build in UIE
  4. Test and run test suit in UIE
  5. Commit code automatically closing ticket as you do so.

The more tightly integrated things are, the less needless work you need to do and the more effective you will be as a developer. It is worth taking the time to get your IDE to be integrated. How much time is a difficult thing to estimate. In “”the mythical man month” Fredric Brooks talks about a team having one person dedicated to writing tools.

We have bigger, more powerful tools nowadays, but in a team it may be well worth having at least one person dedicated to improving the developer experience. The maths is fairly simple. If you estimate that developers can be 20% more efficient with better tools (this will vary massively depending on the technology stack) by the time you have 5 developers the equivalent of one of them will be wasted due to avoidable inefficiencies. So let them choose the tools and have the time to get things running smoothly. And you will have more efficient and happier developers. If you have a team of more than a dozen or so developers seriously consider having someone full time to keep the developers ides and machines running as smoothly as possible.

It is not just getting the developers to work more effectively. Taking the time to have a great IDE setup will pay for itself many times over. Having the bug tracking system right in the IDE will make it easier, and hence more likely that a developer will update tickets as they work. This gives managers better reporting, and stops them from distracting the developers asking for status updates.

tags: