IDEs and the limits of innovation

One idea ran through my earlier article Six tools for a well-run development process, and I'd like to develop it here. I also drew inspiration from a conversation today with Dušan Pavlica (Sun) about innovations and plans for future IDE versions.

There are several ways to think about IDEs and their features. The question is where their development should go in terms of innovation. What should IDEs offer to make them effective tools for developers? Adding one newly popular framework after another can have the desired effect, but it only lasts a short while.

Start by considering what other tools a developer uses alongside the IDE. In that article I described six tools: a source repository, a build system, a continuous integration server, an issue tracker and code analyzers. That list can grow as companies decide what other tools they need.

In the near future, the challenge for IDEs will be integrating with the other tools developers use. Some tools are more suitable for integration than others, of course. Support for source repositories is a good example of how to do it.

In my experience, since IDEs gained built-in support for source repositories, I haven't needed a command-line client. The IDE's support is enough for my daily work, and very convenient to boot. If developers use twenty percent of a tool's features eighty percent of the time, it isn't hard to imagine integrating an issue tracker, for example.

I don't think this should focus only on integrating specific products. The IDE should define an interface through which tools from different vendors can integrate. An intermediary, a connector or adapter implemented by the tool or IDE vendor, would let the IDE components and the other system communicate through the defined interface.

At the IDE level the component, whether an issue tracker or continuous integration, would look and behave the same with either product A or product B behind it. The IDE implements the typical use case for that kind of tool, such as creating a bug report, from the perspective of working in the development environment. It also defines the interface through which that event passes to the external system.

The architecture might look like this.

Image could not be loaded. Archive image in IDEs and the limits of innovation, figure 1

↗ Medium

The Tool API defines the interface from the IDE's perspective. The SPI connector sits between the product and the IDE and is implemented by the product or the IDE developers.

Existing IDEs all use something like the model in the preceding diagram to support extensions. The difference is that the Tool API already provides a concrete implementation for a type of product, such as an issue tracker, build system or CI server. No IDE goes that far today.

This approach is a challenge for IDEs and for the tools themselves.

I'd be interested to hear what you think. Where should IDE development go?