In the early part of the1990s, getting sophisticated development tools to do much was difficult, because hardware was simply not powerful enough to do much heavy lifting. Lucid and Centerline were two companies that went bust in part because hardware could not keep up with their ambitions.

Today, however, the reverse is true: Hardware is under-used in development. To my eye, tools have not advanced enough. The following features, I think, should be standard, rather than rare or non-existent.

IDEs. Designed to make hard things easier, IDEs now make easy things hard. Just try to pop open an editor, type in some code, and do a quick compile-and-run cycle. This is impossible today.

I am presently in the middle of a five-way review of Java IDEs. They all require more or less this sequence of steps: Create a project, determine the type of project to create (Java desktop, Java EE, JSP, etc.), create a directory structure that matches the project namespace, identify where compiled classes go, then finally create the file. The result is that quick, exploratory programming is not supported. It should be.

Second, most IDEs are incapable of dealing with misspellings. Type in the beginning of an identifier name, hit the smart-complete key combination, and if the IDE can’t find a match, you’re out of luck. The IDE knows from the completion request that I expect it to have seen the name, so it should show a list of possibilities that include options with slightly different spellings. Spell checkers do this all the time. IDEs could easily do this.

Third, why doesn’t every IDE have a performance profiler built in?

Debuggers. Even though developers have wanted this for years, almost no debuggers (with very few exceptions—mostly expensive, specialized tools) allow stepping backwards through code execution. This should be utterly standard.

The tool needs only to capture all changed variables and trace the execution for, say, the last 100 statements, and then save this data in a circular buffer. Then if the program hits an exception or a break point, developers can work backwards. Stack traces are about as close as most IDEs come to this today. That is, save for DTrace, we use the same technology for backwards stepping that we used in the 1980s. Surely tool vendors can do better than this.