Development environment of the future

This is a really interesting topic, the topic of the discussion is development environments. IDEs has been one of the most important factors related to developer productivity and is often the starting points for religious debates amongst developers.

Panelists

• Wayne Beaton (eclipse community)
  
• Erik Dornenburg (Thoughtworks)
  
• Bruce Tate
• Cedric Beust (Google)

Cameron Purdy is currently mediating the Panel and he is collecting questions from the audience in writing. I think the fact that he collects questions in writing prevents some effective dialog. People want to talk, not to write so that someone else can talk :-)
Johannes Brodwall (sitting next to me) took up a question related to refactoring and if we are going to see continuing support for refactoring. The panel is not in consensus, Erik claims that we will not see to many new refactorings being developed whereas Bruce points out the fact that the diversity of languages that we are actually using, especially in the AJAX space will require IDE support and continuous effort refactoring support.

Large team support and tools support though collaboration is a very important aspect. Improved integration with communication tools and XP planning tools might me something that can keep us focused in what we do. This a major problem on projects I have been working on. Unfocused developers that are align with fine grained priorities is something that puzzles me. Continuous effort in coaching development teams are something that might be facilitated through the use of an IDE integrated with planning tools (I am not sure if I want a project manager in my IDE .....).

AOP support and support for auxilliary functionality that is not represented as java classfiles like scripting languages, navigation, debugging and profiling is missing. Getting first class support for multiple languages been integrated more easily would be a neat feature.

Cedric points out how neat it is to use a debugger now and then. He urges people that are not using debuggers in java to start doing that instead of using system out printlines. Not much has happened in the debugging space for the last 10 years.

As it seems now, the Java community with IDEA and eclipse is now by far ahead of MS Devstudio while this was quite different only a few years back. This seems to be swinging back and forth, MS DevStudio now getting refactoring support and so on. Myself I am a strong believer of competition and I really think that this will only improve the quality of the tools we are working with.

One reason why Java has been successful is because backwards compatibility has been supported to great length. This means that leveraging existing systems, migrating from one JDK is easier that it might have been. There are a lot of language issues that need to be fixed if we should be able to support stuff like continuations. Thus JVM support for running new languages might be a nice feature.

For those of you that didnt know Cameron is using (as myself) IDEA.

Erik Doernenburg from Thoughtworks answers a question related to BPEL support and workflow support in IDE's by saying that SQL was supposed to be the language that would enable business analysts to write code. Now not even developers use SQL anymore (a pity in my optinion, because the declarative approch in SQL adresses problems, especially in batch applications, that cannot be solved in middleware), so to beleive that enhanced support for business modelling language approaches is a dead end, at least according to Erik.

Closing up the panel, the ultimate question is thrown out, in which direction are we heading:

• java is still going to stand strong
• tools that enable us to work with multiple languages in an integrated manner
• quick feedback related to catching error-situations to reduce roundtrip time
• higher abstractions like AOP and annotation, maybe also metaporgramming (like GWT) will be even more widely supported
• domain specific languages
• lessen the need for code that has to be written, which means less code, even less generated code because generated code will also have to be managed