Apologies in advance to anyone who doesn’t want to hear any more “What I want for IDEA 6.0” threads, but I’m afraid the time has come. I’ve been meaning to write this for a while, but the need crystallized when I had to have three separate conversations with people about whether to purchase 5.0 licenses. I’m sad to say, I was eventually beaten back to defending the position “If you develop for the web, 5.0 is very strong, and in some ways amazing. If you just develop server-side Java, 5.0 has some nice usability improvements, a few cool features, it’s more performant, and there’s a bunch of new inspections. No real 'wow', I'm afraid. I personally think it’s worth pure Java developers paying for, but I could see it being a difficult sell”. This was, as you may imagine, somewhat sad.
Part of the issue is that IDEA 4.5 was in many ways pretty close to being a perfect tool for single-programmer pure-Java development. There just wasn’t a lot of room for discontinuous improvement in terms of functionality. For 5.0, JetBrains decided to relax the “pure-Java” clause of that sentence, providing features for Java developers who also built web pages. For 6.0, I’d like to see JetBrains relax the “single-programmer” clause. Enterprise development is a team sport, and it’s time the best development tool in the world recognized it.
(Yes, I know that a lot of “teamware” has been sold which turned out to be worthless crap. It is a measure of how much I trust JetBrains that I believe they won't do this. They’ve always understood actual developer work patterns at least as well as they understood compiler and debugger internals.)
Here’s some examples of the “team-aware” functionality I want to see:
Deep understanding of version control branching: I want to be able to easily understand and navigate through the various branches of my project’s source control tree. I want to be able to open files from multiple branches either in one project window or open different branches in different windows, with clear visibility of cross-branch relationships and easy cross-branch manipulations. Working on multiple branches will never be easy, but it can surely be made much easier by someone who understands how developers actually use version control systems. No one’s ever managed to do this well before, but I have faith that if anyone can do it, it’s JetBrains.
Collaborative tooling: For every minute of the day I spend coding, I spend another looking over other people’s shoulder at their code, or having them look over their shoulder at mine. Help me make those minutes pleasurable too. Allow me to send files and stack traces to peers, Allow me to share editing or debugging sessions. Let me know what files my coworkers are modifying, before they check them in, so that we can avoid stepping on each others toes. Let me know they are working on something else entirely, so I don't run over and bug them. And yes, no matter how vulgar it may be, let me IM them in a code-aware editor. Presentations on what NetBeans and JDeveloper are working on in this area were given at JavaOne, and actually look pretty useful and impressive. I’m sure you guys can do better. (Note: If you offer http as a transport layer for this, it’ll both alleviate firewall worries and give you a reason to build some kick-ass web services support).
Package up refactoring sequences as migrations. Not every collaboration is so close as to be in the same project. If I can package up a sequence of public signature changes and send them to one of the projects that depends on me in an e-mail, it would enable them to automatically migrate to new versions of my stuff. Third-party libraries could have automatic upgrade paths for their users.
“Best practices” community host site: Similar to the plugin manager, this would enable smaller customizations to be shared from a JetBrains hosted site. Customizations like file templates, live templates, macros, structural-search-and-replace templates, and migrations sequences could be uploaded by community members to this site, and available for downloading and automatic installation by anyone else. Network effects, empower your community, yadda, yadda, yadda.
Remote libraries: Allow me to specify URLs for library content locations, so that a team’s dependent libraries can be managed centrally. This could be a maven repository, Ibiblio, or just an ftp site. Manage fetching, versioning, and caching libraries in the background, so I don’t have to think about it. Someday we’re going to laugh when we see “lib” directories in Java projects, and cry when we have to maintain code that has them.
Resource and library clash analysis: Picture a global inspection that reports every possible class or resource name clash, so that you can have an easy way of seeing that the two XML libraries you indirectly depend on won’t work together. Big projects depend on a lot of stuff, and there’s often no single person in charge of managing all rhe dependencies. Show me that I’m about to step into JAR hell before I have to spend hours debugging classpath issues.
“Runtime-only” libraries. Big projects often have to import a bunch of libraries due to indirect dependencies, but those libraries shouldn’t be actually referenced in the project. Allow me to indicate that while some fool of a library developer decided to depend upon commons-lang, my code absolutely won't use it, so don’t complete, navigate to, or auto-import from commons-lang classes. The module system should make life easier for users, not just be a way of representing complex builds.
Patch creation and application. Obviously.
Directory-level diff and merge. Obviously.
For the last few years, IDEA has helped me to be the best and happiest developer I can possibly be. I honestly don't see how it can get noticably better at that task. It's time for it to help build and nurture the best and happiest development teams that can possibly be.