Code editors renew approach to IDEs

Developers seek more control over productivity with an old programming tool standby

Call it a back-to-basics movement or simply professionals seeking the best tools to get the job done well and on time. With enterprises putting a premium on productivity, a quiet revolution among programmers is eschewing the heavy, feature-filled IDE and turning instead to the venerable standby: the code editor.

The spark behind this growing trend comes down to control — enterprises tout IDEs as the development tool du jour, with supporters arguing that programmers will get more done if they can do all their work inside a single environment. But many programmers (especially experienced ones) prefer a markedly different approach, using code editors and pluggable modules, modes, or other extendibility features to pick and choose just the tools they need. They don’t enjoy being shoved into a single development environment, and contend that IDEs are resource-intensive, slow, and have many more features than are really needed to get the job done.

The answer lies in a flexible tool strategy: Developers get to use the tools and approaches that help them work best, and the company reaps the productivity benefits of both efficient tools and happy programmers.

Going modular

The modular, code editor approach is appealing on several fronts. First, these tools are generally low cost — and frequently no-cost — items, so experimenting with a modular development strategy to increase programmer productivity in the enterprise does not require a large chunk of the budget.

Many modular code-editing solutions are derived from and maintained by open source developers. In fact, the involvement of the open-source community is one reason for code editors’ recent rise in visibility, as the vast majority of code editing solutions available today are open-source, multi-platform, and multi-language.

“My students don’t usually have a lot of money to throw around,” says Tom Sinclair, a computer programming instructor at Westwood College of Technology. “We typically use as many free and low-cost solutions as possible. Open source editing tools, in particular, provide an easy approach for both our Linux and Windows development.”

Open source roots provide yet another benefit: source code availability. Programmers using open source editors and modular plug-ins can easily customize their tools to meet corporate standards, such as a shared plug-in that all internal developers can use to perform automated check-ins to a specific source code repository.

Extending and adapting open source tools with additional modules also puts the collective knowledge of other developers — who have likely uncovered better, faster ways of doing various tasks and already updated the modules — directly into your hands, boosting productivity further.

But customization is just one piece of the code editor puzzle. Programmers have some lively answers when it comes to what sets code editors apart from other development tools.

“The editors in most IDEs don’t have nearly enough features and they make manipulating code difficult,” says Chris Rathman, a consultant and software developer. “For example, I need to be able to work with several hundred files in a single session and I must have the ability to do global search and replaces. Oh, and it has to be fast.” 

Many developers feel that mouse-centric IDEs slow them down, while keyboard-driven code editing tools’ feature-rich and flexible nature gives them an edge. “I’ve yet to use an IDE where I can enter or edit code as quickly as I can using Vim,” adds Wade Bowmer, a senior developer at Excido. “I don’t need to use a mouse, and many IDEs heavily use the function keys, which seems to really slow me down.”

Scott Anderson, a senior software architect, agrees. “I use Emacs for everything. It’s programmable, open source, has a huge user community, and its range of features is simply stupefying,” he explains.

Developers from a variety of shops echo the same themes: The code editor approach gives them modular tools that support multiple languages and platforms, along with features such as syntax highlighting, macro facilities, usable file comparison tools, a multilayer cut and paste function and powerful search and replace capabilities.

But regardless of features they consider important, programmers still place productivity gains ahead of all other benefits. 

“People who observe me working in Emacs are usually amazed at how much I get done in a very short period of time,” says Anderson. “I’d say we’re talking an order of magnitude, at least. We’re always trying to find tools that will help our programmers be as productive as possible.”

Plugging in

Flexible code editors with the right features and high productivity aren’t the only high points of this modular philosophy. The pluggable modules and extensible modes that enable specific task types are a large part of what makes the code editor programming paradigm work.

The number and types of available modules and modes available is staggering. For example, if your shop uses the XP (eXtreme Programming) methodology, there are plug-ins available to map to the releases, iterations, stories, and tasks that must be executed for XP projects. Likewise, if your site does a lot of refactoring, available plug-ins can help automate the process, usually by maintaining catalogs for refactoring activities. After selecting a catalog entry and setting parameters, the plug-in analyzes the impact of the refactoring operation; if the developer agrees with the output of the analysis, he or she can use the same plug-in to then execute the refactoring operation.

Other plug-ins support a range of actions, from the creation of Apache Ant scripts to XML indenting and SQL accessibility, as well as allowing access to source control tools, such as CVS and IBM’s Rational ClearCase.

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.

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.