Editorial Note: I originally wrote this post for the SmartBear blog. You can check out the original here, at their site.
If you’re a software developer, there’s a decent chance you’ve been embroiled in the debate over integrated development environments (IDEs) versus text editors. Users of IDEs will tell you that they facilitate productivity to a degree that makes them indispensable, whereas users of text editors will tell you that the IDEs are too big and bloated, and hide too much of the truth of what’s happening from you. In some cases, depending on the tech stack and personalities involved, this can become a pretty serious debate.
I have no intention whatsoever of wading into the middle of that debate here today. Rather, I’d like to tackle this subject from a slightly different angle. Let’s take at face value that text editors are comparably feature-poor but nimble, and that IDEs are comparably feature-rich but laden with abstraction. Framed as a tradeoff, then, it becomes clear that realizing the benefits of one choice is critical for justifying it. To put it more concretely, if you’re going to incur the overhead of an IDE, then it had better be doing you some good.
With this in mind, what should you expect from an IDE? What should it do in order to justify its existence, and what should be a deal breaker if missing? Let’s take a look at what’s reasonable to expect from IDEs.