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 in the US. "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 in the US. "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.
A Time and Place for IDEs
No matter how productive and flexible developers are when using a modular code editing approach, there are times when an IDE makes sense.
Creating GUIs and using change-management tools to deploy code to production are two uses where IDEs shine. Scott Anderson, a senior software architect, concludes that "the only thing I use an IDE for is GUI design."
Likewise, iSoft Senior Programmer Glen Austin says that "IDEs make GUI development a breeze. I usually use the IDE to design the GUI and then change the underlying code to dynamically create the interfaces."
If your production environment includes deployments to server platforms, such as IBM iSeries or application server platforms, such as BEA WebLogic or IBM WebSphere, it may make sense to use an IDE in the final leg of the cycle to more easily move applications into production. For example, SoftLanding Systems' TurnOver change-management tool can help you deploy applications from within IBM's WebSphere IDE. Likewise, working within BEA's WebLogic Workshop IDE allows you to rapidly prototype things locally in an integrated test application server or deploy to production with ease.
IDEs may also make a good starting point for analysts and developers to work on application design and modeling. The development lifecycle would start by using IDEs to rapidly develop designs and do some prototyping. Once the design is "dialed in," developers could then use either the IDE tools or a modular code editing approach to complete the project cycle.
Aside from these types of very specific tasks, the decision to use an IDE should be largely based on usability, skill level, and developers' personal preference. The developer comfort factor with IDEs can be a boon, and some developers find that particular built-in tools make problem resolution that much easier.
"Borland (Software)'s IDEs are the standard and their tools are awesome. In particular, (Borland's) OptimizeIt suite of tools helped us quickly locate the bottlenecks in our code," says Austin. While there are profilers for code editors that provide equivalent functionality, OptimizeIt's solid implementation gives it an edge; many developers will use this tool even if they don't like IDEs.
IDE proponents contend that their integrated approach provides the handholding newer developers need, too. By making everything available from a single interface, IDE providers feel that newer developers will find tools, help, and code examples more easily accessible. In the case of Visual Studio, for example, David Lazar, director of Microsoft's developer division, points out that "Visual Studio provides an extensive library of code to copy and paste as well as technology that makes it easier for developers to learn language fundamentals and things like proper syntax."
Though IDEs may currently allow users to take a code-editing approach to development, many are simply limited to the code-editing tools supplied by vendors. There are few provisions that allow developers to plug in other tools of their own choosing.However, this may be changing: Lazar notes an interesting trend on the rise, involving the blending of the best of modular code-editing methodologies with visual IDE-based development tools.
In this scenario, "the developer has the choice of using a high-level approach (such as Visual Basic developers) or spending most of their time working with code editing tools (such as C++ or C# developers)," explains Lazar. These open, extendible IDEs -- along the lines of Eclipse -- are shaping up to be the likely model for future IDEs.