IDEs need rethinking

IDE stands for Integrated Development Environment. If you look it up in Wikipedia, you find that an IDE denotes a software application that provides comprehensive facilities to computer programmers for software development. In other words, an IDE should provide tool support for all activities that appear during software development.

But, what is software development? Again, Wikipedia will tell you that it denotes all that is involved between the conception of the desired software through to the final manifestation of the software.

And, what is all? Well, the most obvious part stems from the observation of the process from outside: at the beginning of the process there isn't a system, and at the end there is one. Thus, there must certainly be a building part. Indeed there is, and we spent a large amount of effort to learn how to approach this part. We built high level languages, we crafted sophisticated technologies, we distilled lessons learnt in the form of various kinds of patterns. These are all valuable and available now. On top of that you have the IDE to help you assemble the system and make all these wonders available at your finger tips. Typing and managing code has probably never been easier.

However, if you take a closer look at how engineers spend their active time, you will see that some 50% of the time, theoretically dedicated to the building part, is actually spent on understanding the current system to figure out what to do next. This is not about building. This is about assessment. And what is the state of the art you can rely on to deal with this activity? Leaving the almost inexistent patterns aside, you should at least have the IDE at your side.

Do you? Certainly, you do have some help. The code is nicely formatted and syntax highlighted which makes it easier to grasp its structure. Search is supported to some extent, especially if you know the exact name you are looking for. Completion supports local understanding. But, here is the thing, most of these are highly local or limited.

The fundamental problem is that the IDE is highly built around editing code. That might be fine for half of the use cases, but it is insufficient for the other half. Take a look at the screenshot below:

Most of the screen is occupied by the text editor. It is true that this is where the system is, but consider it in perspective. Typically, with the window maximized on a laptop screen you will get some 40 lines of code displayed … of perhaps several hundred thousands. It is like investigating the situation by always walking around with a magnifier glass. This is a good way to approach detailed inspections, but it is not useful for understanding the big picture. There are some tools that provide some help, but again rather limited. For example:

• the index to the left is just that: a simple index; and
• search is typically limited to finding entities based on one single dimension such as: simple name matching, or call graph.

In a way, the design of the IDE is natural: it started as a simple code editor, and afterwards more and more features were added gradually. But, they were all built around the code editing metaphor.

This is no longer enough. At the very least, they need to move away from this metaphor. There is no reason why the first thing offered by the IDE is the editor. After all, before editing, you first have to understand. Why does the main screen of the IDE not rely on a powerful search bar by default that would offer you the possibility of easily looking for classes that are annotated with @Session and are called directly from subclasses of Swing components? And why is there no visual map that provide a global picture and help find your way around the system?

IDEs need rethinking.

There is hope. For example, inCode enhances Eclipse with visualizations and several kinds of detections. Or we have newer IDE metaphors, such as Code Bubbles that for the first time start with an empty canvas and help you manage larger contexts through multiple little editors that are logically connected. These are nice steps, but there is more to be done.

Assessment is an important activity that must be supported explicitly. Until the IDEs catch up, you should look for extra tools to help you deal with it. You can always count on Moose.