Intellij IDEA has been an amazing professional-grade IDE for the last 20 years. However, as computer programs evolve, so must the IDE keep pace to remain a useful tool.

What's Changed?

A typical organization in the 2020s has:

  1. Hundreds of microservices
  2. Hundreds of git repos
  3. Polyglot codebase
  4. APIs defined with HTTP/JSON/GRPC, not just programming language interfaces
  5. Runtime service inter-dependencies
  6. Cloud service dependencies

Let's go through how each of these could impact the design of the IDE of the future. I will be using Intellij for comparison since it's the most advanced IDE currently.

Big Code is the new Big Data

With huge amounts of code across hundreds or even thousands of repos, the IDE has to now deal with 'Big Code'. It's big not just due to the sheer lines of code. It's the fact that it's divided into microservices, each of which has a separate set of dependencies, which the IDE now has to separately index. This can exponentially increase the amount of code to index compared to a single large codebase without so many external dependencies like the Linux kernel.

All operations in the IDE must assume huge amounts of code across hundreds of repositories, not all of them might be checked out locally. So things like Refactoring, Find Usages, Call hierarchy, etc have to be re-architected to run as long-running operations over code that could be both local or remote and still give users a seamless experience.

Refactoring

Refactoring so far has really been a single repo feature. But what if the code you are refactoring is called by code in 100 other repos in your organization? What if those repos are not even checked out locally? The modern IDE needs to evolve beyond single repo operations. Maybe that rename refactoring now becomes a long-running operation that creates Pull Requests in various repos. This is not an easy problem to solve. Google even has a paper on this:

The complexity grows as API calls happen across services in various languages now and use HTTP/JSON or GRPC/ProtoBuf. Renaming a struct in one repo that gets serialized to JSON during an http api call might require renaming a similar struct in a whole different language that deserializes said JSON. This is way more complex than a simple Java function rename refactoring.

Version Control UI

Version Control features in IDEs are really built around browsing/editing one git repo at a time. This simply doesn't work when your codebase is spread across hundreds of repos. The fundamental interface for the Git UI in Intellij (and other IDEs) needs to be rethought to deal with a large number of repos.

Rethinking the 'Project' model

Currently, an Astradot engineer has to check out a git repo, eg https://github.com/astradot/kafka-schema-sync, open the IDE, point to it, which will create an Intellij 'project' for the repo or a 'module' for an existing project. This is backward. The IDE should ask for the Github org eg, github.com/astradot and it should create a single project that contains all the repo as modules. It should then manage lazy-loading/lazy-checkout or whatever is needed to give me a seamless experience browsing the code of my entire org.

'Run' button

The 'Run' button will need to have more intelligence than simply running your app. In a microservice world, your service might depend upon an 'auth' service which might require a Postgres database and Redis instance initialized to some state. The services may rely on k8s service names to communicate, thus requiring running inside k8s. The IDE will need to be aware of the environment where you want to run your services and initialize the dependencies appropriately when you hit the 'Run' button.

The traditional debugger though is not going anywhere anytime soon. Take that from a guy who wrote a time-traveling one, once upon a time. Though IDEs could take a page from APMs and benefit from showing a distributed trace in addition to breakpoint-based debugging.

What's not the future

Silicon Valley has been obsessed with making 'IDE in the Cloud' happen for the last decade. Every year a new set of cloud IDE startups is funded while the old ones die off. None of the problems they are solving help professional engineers.

From an Astradot engineer's perspective:

  • Downloading and Installing Intellij is a non-issue
  • We have scripts to setup your workstation environment within minutes with all the needed compilers, tooling, etc.
  • We never need to see each other live code. That would be annoying/intruding on the other engineer's privacy.
  • Workstations are powerful enough that they can run the entire Astradot locally.

We would love to buy all our engineers 64 core Threadrippers w 128Gb ram if the IDE could make use of it.

Conclusion

The IDE of the future is very different from what Intellij is today, both in terms of its architecture and UI. It requires solving some hard computer science problems. Jetbrains seems more focused on making just evolutionary changes to its IDEs to keep it ahead of VS Code. This is an opportunity for a new startup to rise.