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.
Another longstanding problem is the inability of debuggers to work across system edges. Send a data packet to another system and, to speak of, you have no way to follow its progress. Why not create debugging tools that can span systems so that you can watch data as it moves across systems—pause it, inspect it, modify it and so on—regardless of platform?
Debugging multithreaded apps is still a horrid chore. There has been almost no progress in this area despite the advent of the multicore era. When an execution passes from one thread to another, most debuggers cannot follow the movement of the locus of execution. Why not? If this can’t be done by the system due to the complexities of the specific application, how about allowing developers to specify a known sequence and have the debugger follow that? This, at least, would make message passing across threads easier to debug.
Build systems. Of all primary tools, build systems are the least tuned to the needs of their intended users. Debugging Ant scripts or trying to bend Maven to do a task it does not expect highlight how fractious these technologies can be. Not only are they balky, with remarkably little support for debugging, but they do almost nothing automatically, save understand dependencies.
For example, no build tool I know of automatically validates the final deliverable against the inventory of files it should contain. The tool knows what files should be in there. Why is there no automatic validation option to make sure component files are in there and readable, such as validating against the checksums to make sure I/O was done correctly? How about validating that the package contains no viruses?
I don’t want this to sound like I’m ragging on tools. I’m not. I am intensely aware of how superior tools today are when compared with their counterparts 10 and 15 years ago. I also know that all the limitations I’ve mentioned can be solved manually by developers. But with four cores on my system and several times more RAM than I need for development, I’d sure appreciate more help from tool makers—far more than I’d care for yet another Web framework.
Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.
