The great IDE debate

Although I don’t write much code in my daily work as CTO, I do occasionally dip my toe into the code-writing waters. Because I come from a development background myself, I take an active interest in the procedures and processes of my development team. Generally, though, I let those guys run free as long as they are using basic best practices to get their work done. Those basic best practices include simple things such as source-code control, reusable code writing, peer code reviews, and most importantly, consistently hitting project milestones with code that works and scales.

As a Java shop, we have our choice of dozens of tools to produce our code, but our developers have opted for the humble text editor. Our developers use a wide variety of text editors within the team (UltraEdit-32, vi, and Emacs), but each developer basically sticks to the simple text file environment. Our team is highly productive and probably the best at hitting deadlines that I have ever managed, but when it comes to writing code, IDEs (integrated development environments) just leave them cold.

I started thinking about IDEs again recently when I decided I wanted to really learn Java after a number of false starts in the past few years. This time, I had a real-world mission in mind — I wanted to learn how to extend our Salesforce.com implementation using the vendor’s sforce development platform. The Eclipse SDK, an open source IDE from Eclipse.org, seemed like a quick way to get started based on what I had read. As any good manager would do before diving into such a project, I asked the developers on my team why they had chosen not to use IDEs to do their work. The answer was pretty predictable: They thought the level of abstraction that visual IDEs brag about was more a detriment than a benefit. One of our developers compared building code in an IDE to using a WYSIWG editor to build Web pages — doing HTML by hand results in cleaner pages, and you know exactly how they work when you’re done.

We’re not the only ones who prefer to get things done without IDEs. As I write this column, there are five open software developer positions at Overture, the advertising services company purchased by Yahoo last summer in a deal valued at $1.6 billion. The requirements are fairly typical for anyone looking for Perl/C/C++ developers, but one point caught my eye: “The team does not use IDEs to develop applications.” Although this might appear to be an unusual statement to make in a job posting, I admire its directness. It will filter out vast numbers of applicants who might not be a good fit for the existing team.

The IDE debate will probably continue until the end of time. A surprising degree of passion flares if you bring up this issue with developers. But does it actually matter? The answer, like any dealing with the ambiguities of IT philosophy, is yes and no. As long as your developers produce quality code that they can debug at the lowest level when necessary, the IDE debate is probably more of a cultural issue than a technical one. Consistent, quality code delivered on time trumps the means of getting there; however, culture matters within a development team. If your development team spends a lot of time debating the merits of writing code in an IDE or a simple text editor, they probably won’t be incredibly productive. The important thing is to choose the route that makes your team most productive — and execute.