Code editors renew approach to IDEs

By contrast, many traditional IDEs limit developers to just the tools and modules included out-of-the-box by the vendor. This one-size-fits-all approach may work for some, but maximizing productivity for all developers on a team can be more easily addressed by using the modular, pluggable tool strategy. Some IDEs are taking this to heart; more open IDEs, such as Eclipse, are beginning to implement a flexible development approach by offering one or more editors and pluggable modules within the IDE.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

Other modular editors offer mode capabilities that allow programmers to customize development tools for one or more programming languages. Modes supply the language-specific functionality needed to write applications, and programmers simply switch modes to write applications in different languages. For example, suppose your team develops applications using XML, Visual Basic.Net, C++, C#, Java and J2EE. Rather than using three or four different tools to support your development efforts, you could use a single code editor that offers modes for all of these languages.

The modularity of a code editing tool strategy may offer a great deal of flexibility by giving developers just the specific tools they need to achieve rapid results, but getting the most out of these tools still requires developer knowledge and skill level.

As Glen Austin, senior programmer at iSoft Corporation notes, “the deeper one understands a given programming language, its libraries and features, the faster and better their code will be. Deep understanding doesn’t just come from pointing and clicking.”  Developers with some experience may take more quickly to — and get more benefit from — the more nimble and streamlined code editors simply because they are more familiar with the languages and processes involved.

When it comes to expanding developer skill levels or teaching new programmers, there is some debate about whether code editors or IDEs are the right way to go. An IDE’s extra features can act as a set of training wheels for new developers, depending on how much knowledge they bring to the table at the start. However, many of those who adhere to the code editing philosophy believe that junior programmers have an easier time learning the fundamentals of a programming language using a code editor because the new developer is not saddled with learning the bells and whistles of an IDE.

“Emacs is very forgiving of new users,” says Anderson. “It has a built-in tutorial, and context-sensitive help and assistance is readily available from the user community.” Excido’s Bowmer notes that “Vim includes a tutorial called Vimtutor that quickly teaches you the basics. I personally found Vim very easy to learn.” Meanwhile, Rathman says that “TextPad would be a good choice [for new developers] because it offers a good balance between simplicity and features.”

Investigating the other side

If your shop wants to consider a flexible, modular approach to programming, you needn’t abandon your current development tool standard. If you currently use an IDE, find out if that IDE is extensible to the point where programmers can plug in a variety of editors, debuggers, and other selective tools on an as-needed basis.

One way to gauge the effectiveness of your current development tool strategy is to track the number of production-level problems found in a given piece of software (It’s one thing if programmers complete the development and test cycle rapidly, but quite another if that same code has frequent problems in production). Metrics showing the number of production problems and the time spent resolving them can provide an eye-opening assessment of whether the development approach you have in place is best for your team.

Of course, there are plenty of gray areas in this quest for development nirvana.  There are open, extensible IDEs that let developers plug in tools of their choosing; there are also code-editing solutions that “plug into” an IDE. For example, Visual SlickEdit provides a plug-in so developers can use it from within IBM’s WebSphere Studio Application Developer IDE.

Given the low- (or no-) cost nature of code editing tools, modes, and pluggable modules, have some of your developers try one or more of these solutions and give you an assessment. For some team members, checking code in and out of a repository and into an IDE may be best, but other programmers may find that repository interaction with pluggable code editing tools is a much better fit for their working style.

Choosing an IDE or modular code editing approach is not an all-or-nothing proposition. Wise enterprises are those that leverage the best of both these worlds to create development methodologies that deliver results. Code editors support multiple languages, platforms, and mixed developer skill levels, adhere to corporate standards, and often lead to the productivity gains. If giving developers a little control over the tools they choose can spark all those benefits, a flexible tool strategy becomes an easy choice.