Why I don't use a traditional IDE...unless I have to

I don't really think I'm a luddite when it comes to technology but there is one piece of technology that I don't think I will ever truly embrace; The modern IDE.

I feel I need to make a disclaimer from the start. I don't think it's wrong to use IDE's and in fact I'd argue that there are certain times where it's important to use an IDE. But, I do think that becoming dependent on the modern IDE makes you a poor software engineer.

I think I should start with why I keep saying modern IDE and not just IDE. In general an IDE is any development environment that gives you the ability to write, build, and debug software. With this definition a text editor wouldn't be considered an IDE but an argument could be made that VIM is because of it's built in ability to run shell commands.

In contrast here are a few features that most modern IDE's provide.

• Intelligent code completion
• WYSIWYG UI editor
• Static code analysis
• Some notion of a solution or project
• Code templates
• Refactoring tools
• Deployment tools
• Code/Database modeling tools

Those all sound like great add-on's don't they? While most of them can be very useful tools here's why I think some of them are more harmful than helpful to the average software engineer.

Intelligent code completion

Most developers I know will argue day and night that if you take away their intelligent code completion that they'll significantly slow down as an engineer. Intelligent code completion allows you to start typing a word and the IDE will provide you a drop-down of options applicable to your context. Sounds great doesn't it? Here's why it's not.

It discourages the engineer from learning the API, Framework, SDK, or toolkit that they're working with. All you have to know is the keyword you're looking for and the code completion will do the rest. The designers of the API/SDK/Framework, or etc that you're using put things in certain places for a reason. The more you understand about the structure of the API/SDK/Framework the better you understand how it's designer(s) want you to use it. This becomes very important when trying to do something new with a framework as you have a better understanding of how to compose objects in the framework to build more robust pieces. If you don't understand the intended use of objects in the API/SDK/Framework you may, as is often the case, try to shove a square peg through a circular hole.

WYSIWYG UI Editor

This is actually the least harmful feature modern IDE's provide. I added it to my list because, like intelligent code completion, it discourages the engineer from learning how the UI framework works. I do believe that after the engineer has really learned the UI framework and understood why you do things the way you do for a particular framework use of a WYSIWYG can be very helpful as it abstracts away a lot of the annoyances with UI layout and composition.

Proprietary Solutions/Projects

This one is one of the more evil features of a modern IDE. Most modern IDE's have their own way of organizing the resources and dependencies required to build a project. This in and of itself is not a bad thing. The problem arises when the rules for organizing and the file format used to describe the organization is closed. What this means is that if you use the IDE's built in solutions/projects you're making it so that you can ONLY use this IDE with your project.

Software engineers are a fickle group. I challenge you to find a team of developers that has their development environment exactly the same. That is, the same tools, the same configuration, the same defaults, and etc. You won't find it. Even the best organizations that try to standardize their development environments are usually fighting an uphill battle. This is because, as engineers, we all approach software engineering slightly differently. The configuration we use, the defaults we choose, and the tools we have installed are things that help us, individually, become better engineers. But that doesn't mean that a tool that makes me a better engineer is going to make you a better engineer.

Another big problem that proprietary solutions/projects have is flexibility in using best in class continuous integration servers. When the IDE has a closed solution/project structure it becomes more difficult using 3rd party tools to build your application. You may find plugins that allow the server to integrate with your particular IDE but it's a hack at best unless it's an official plugin provided by the vendor of your IDE. I say it's a hack at best because the closed nature of the solution/project organization format means that anything can change between versions of the IDE. This poses a problem if you want to stay current with the latest version of your IDE as well as the latest version of your integration server.

An IDE should be a means to an end and not the end itself. If you can't build and distribute your program without a particular IDE you will be fighting an uphill battle when trying to use best in class build integration servers, on-board new engineers, share your code with people outside your group, or open source your software.

What this means in the real world

My goal with this post isn't to get you to stop using IDE's. It's to get you to start understanding the trade off's with using a particular IDE so you're prepared to handle the downsides. At the end of the day there are going to be certain frameworks (like iOS) which are not built to be developed outside of a particular IDE. But, if we raise enough awareness about what we want to do outside of these IDE's we can get the framework designers to provide a more robust development environment and we will be better software engineers.