Should your developers use an IDE to develop software? If you think that discussion ended years ago, think again. The voluminous response to my Aug. 30 column proves that the debate rages on.

As you may recall, our operation at InfoWorld is an IDE-free zone. So it should come as no surprise that I got lots of responses from the pro-IDE crowd, which enjoyed poking holes in the assertion that using an IDE results in blind code generation. Ari Shapiro, senior software developer at a large software company, represents this camp:

“With all due respect to your developers, they are being very foolish. I have been programming in Java since 1997, writing my first Java apps in XEmacs on Solaris. Today I am much more productive because I use an IDE. Not because the IDE generates code for me; the IDE makes it easier for me to write code. A good IDE is much more productive than Vi, UltraEdit, or any other text editor, period.”

On the other side of the argument, Richard Huntrods, a Java instructor and programmer with 25 years of experience, points out the pitfalls of using an IDE when teaching students programming concepts:

“I have this very discussion with my students…at the beginning of every semester — like just this week. I have been recommending a freeware editor used in combination with the Java JDK and either Ant or a DOS window since the beginning. I find that it frees the student to learn the language (and how to program) instead of fighting with irrelevant stuff thrown up by an IDE. I’ve also taught classes in the past where, for a variety of reasons, one or other specific IDE has been mandated for the course. Invariably, I spend more time teaching the IDE and helping students with IDE issues than I do actually teaching the language.”

An e-mail from Mike Arms suggests that, as with most debates, the truth resides somewhere in the middle:

“In our development groups, use of IDE vs. text editor varies widely. But in our team, we have settled on using IDEs for rapid development of GUI code, especially for quick turnaround to support changing customer needs or to add custom GUIs for particular customer groups. And likewise, we tend to use text editors for server apps, middleware, servlets, most other non-GUI code, etc.”

In a debate that can be surprisingly contentious, Mike’s point of view seems, well, totally reasonable. In the end, I’m not sure that choosing one side or the other is as useful as thinking deeply about the overall approach to development. Even partisans concede that what really matters is the consistency of results you achieve, not which tool you choose.

If an inexperienced developer uses a visual tool to abstract coding to the point of not really understanding how a problem is being solved, debugging that code later is going to be painful. At the same time, increasing levels of abstraction have been a prerequisite for progress in many human endeavors. Should my accountant do my taxes on paper to prove that he knows math? Not when I’m paying him US$100 an hour; any competent accountant would use a calculator for simple math and Excel for complex formulas. Talent in any field comes down largely to knowing the available tools — and the right moment to put one tool down and reach for another.

Chad Dickerson is CTO of InfoWorld.