Integrated Development Environment

Well, really, I suppose your environment doesn't need to be fully integrated. For a long time, my toolset was a combination of Project Builder, Interface Builder, WebObjects Builder, EOModeler, and Edit. It does need to make you more efficient than the simple "text editor and make" combo of yore.

What's the big problem? Why so harsh on the text editor? Any time you have to stop making software to deal with your tools, there's a chance you'll lose concentration, forget what you were doing, and have to spend a few minutes reacquainting yourself with the problem. Losing a couple of minutes doesn't sound like too big a deal, but if you're doing it a couple of times an hour every working day, it quickly adds up to a frustrating drop in productivity.

You're going to be using your IDE for most of your working day, every working day, for the next few years. You should invest heavily in it. That means spending a bit of money on a good one that's better than the free alternatives. It means training yourself in the tricks and shortcuts so you can do them without thinking, saving the occasional second and (more importantly) keeping you focused on the work. It can even mean writing plugins, if your environment supports them, so you can do more without context-switching.

In some plugin-rich environments, you could go a whole day without ever leaving the IDE. For example, Eclipse now includes the Mylyn (http://eclipse.org/mylyn/start/) task-focused plugin, so you can interact with your bug tracker inside the IDE. It'll also let you focus your views on only those files related to the task you're currently working on.

Not only do you need to go deep on your chosen IDE, you need to go broad on alternatives. A future version of your favorite tool might change things so much that you'd be more efficient switching to a different app. Or you might start working on a project where your preferred IDE isn't available; for example, you can't (easily) write a Mono app in Xcode, or an Eclipse RCP application in Visual Studio.

This restriction of development environments to particular platforms, whether done for technological or business reasons, is unfortunate. This is where the "just use a text editor" crowd has a point: you can learn emacs just once and whatever language you end up programming in, you don't need to learn how to use the editor again just to write code. As you're going to spend your whole working life in one of these environments, every change to features you already know how to use represents horrendous inefficiency.

Notice that all of the aforementioned IDEs follow the same common pattern. When people have the "which IDE is best?" argument, what they're actually discussing is "which slightly souped-up monospace text editor with a build button do you like using?" Eclipse, Xcode, IntelliJ, Visual Studio… All of these tools riff on the same design—letting you see the source code and change the source code. As secondary effects, you can also do things like build the source code, run the built product, and debug it.

The most successful IDE in the world, I would contend (and then wave my hands unconvincingly when anyone asks for data), is one that's not designed like that at all. It's the one that is used by more non-software specialists than any of those already mentioned. The one that doesn't require you to practice being an IDE user for years before you get any good. The one that business analysts, office assistants, accountants, and project managers alike all turn to when they need their computer to run through some custom algorithm. The most successful IDE in the world is Excel.

In a spreadsheet, it's the inputs and results that are front-and-center in the presentation, not the intermediate stuff that gets you from one to the other. You can test your "code" by typing in a different input and watching the results change in front of you. You can see intermediate results, not by breaking and stepping through, or putting in a log statement then switching to the log view, but by breaking the algorithm up into smaller steps (or functions or procedures, if you want to call them that). You can then visualize how these intermediate results change right alongside the inputs and outputs. That's quicker feedback than even REPLs can offer.

Many spreadsheet users naturally adopt a "test-first" approach; they create inputs for which they know what the results should be and make successively better attempts to build a formula that achieves those results. And, of course, interesting visualizations such as graphs are available (though the quality does vary between products). Drawing a graph in Xcode is… challenging. Indeed, you can't do it at all, but you can get Xcode to create an application that can itself generate a graph. The results are a significant distance away from the tools.