Arguments Against IDEs

(Published on 2023-02-23)

Throughout my carreer as a programmer, the use of integrated development environments has been the norm rather than an exception. I myself used IDEs for many years, but have come to avoid if not outright shun them. The arguments for using an IDE are plentiful: It makes refactoring easier, it makes debugging easier, it allows you to write code faster, and so forth. In this article, I’m going to detail some of my own arguments for not using an IDE, because I find it’s viewed as a somewhat novel position, and one that I keep having to explain and justify.

I am not claiming that I am in possession of the Truth, and that others should replace their ways of working with mine. I think everyone should be allowed to work in the ways they prefer, whenever that is possible. Just like I don’t want to exclude anyone for using an IDE, however, I also don’t want those of us who are more comfortable outside an IDE to feel unnecessarily excluded. Additionally, as I’m going to argue for, I think there are definitive benefits to running projects that are development environment inclusive, regardless of whether you yourself are using a particular IDE or not.

IDEs Can Be Premature Optimization

Integrated development environments were invented to solve a number of perceived problems that I’ve already touched on. Before adopting a solution, however, it is worth taking a step back and ask if the problem being solved is an actual problem in this project. Increased development speed is for example often touted as one of the major benefits of using an IDE, and it’s hard to argue that you aren’t able to write, or refactor, more code quicker by using an IDE. But I think this “straight line” way of thinking can be deceptive.

What is it that takes time when programming? For me, it is without a doubt all the thinking I need to do. The time it takes me to type in a complete program is completely negligable compared to the time it takes for me to figure out how the program I want to type in should work. So optimizing for faster typing time is only ever going to bring marginal benefits for me. In fact, I would argue that the extra time spent typing is also extra time spent thinking, and that thinking things through as you type can actually help you spot flaws in your design that you would’ve otherwise missed. If you buy that line of reasoning, then you would recognise that in some cases, using an IDE as a typing aide can actually end up slowing you down in the end.

IDEs Can Hide Problems

Another major advantage IDE advocates like to champion is convenience. An IDE can automatically manage all your messy imports/includes for you! With an IDE, you don’t need to think about where a file is located in a project structure – you can just jump straight to it!

This kind of convenience comes with the risk of adding invisible complexity to your project, though. Personally, I hate it when complexity goes pretending it doesn’t exist, because that makes it so much harder to discover and address. Take automatic management of imports, for example. Having to manually type in and/or update dozens of imports is very tedious, while an IDE can reduce the effort to zero. But that’s a solution that shoves the symptoms (many imports) under the rug, instead of addressing the actual problem (lots of dependencies)! The proper solution in that case would be to have an architecture in place where imports are limited and logical, and without the crutch of an IDE to help you out, this solution becomes much more natural to spot.

IDEs Can Create Lock-In Effects

My own experience working with developers who are IDE users is that they often don’t know how to do certain things outside of their IDE. That’s not to say I haven’t worked with plenty of IDE users who have also been both very skilled and capable outside of their IDE of choice, but as a generalisation I think there is at least some merit to that observation. In a specialised project this can also turn into a feedback loop, where new developers are taught how to do things by old developers, who only know how to do those things in their IDE, thus reinforcing the lock-in.

At any given point in time in a project’s life, IDE lock-in is typically not a problem. It will become an issue for example if the IDE in question suddenly can’t be used, be it for reasons of obsolescence, legal concerns, changing platform support or something else. It may also be that you realise that you want to use a continuous integration system, for example for running automated tests or improving deployment processes. In a scenario like those, you could find yourself in a situation where you need to not only invest in learning a new environment, but potentially also have to restructure the project and set up an entirely new build system. Adopting development environment inclusivity from the start can mitigate this risk to a very large extent, because by setting up your project to (at least potentially) support multiple development environments from the beginning, adding support for a new environment is much less of an effort.

Conclusion

These are some of the arguments I like to present when people enquire as to why I’m insisting on working in a text editor, and on using command line tools. There are more arguments I could make, but my intention was again not to convince anyone that they should stop using their favourite IDE – only to demonstrate that not using an IDE is still a valid choice, and also one that there are certain merits in enabling.