IDE evolution continues beyond Eclipse

During the last decade, both recently graduated and currently employed software developers have increasingly adopted graphical integrated development environments (IDEs) as a replacement for traditional command-line tools. This trend encompasses all types of programming, from the enterprise all the way through embedded development.

The forces driving this trend include ever-increasing size and complexity of application code, the need to automate and accelerate the build cycle to accelerate time-to-market, the requirement to streamline training and make developers more productive more quickly, and of course the near ubiquitous availability and use of products like Microsoft Visual Studio for Windows application development and the emerging Open Source Eclipse environment for Linux and other platform development.

Time-to-market vs. complexity
Time-to-market pressure on software developers climbs year over year. Projects delivered in 18 to 24 months in 1994 must now leap from concept to delivery in just 9 to 12 months. Even as development pace has redoubled, software content has grown dramatically. As complexity grows, software developers are expected to become even more efficient and to work in collaboration with increasingly large and increasingly distributed teams.

There exists a core metric in software engineering - a tenet which states that programmers can produce 7 + or - 2 lines of maintainable code per day. The whole history of software engineering has focused on making that creative act more efficient by letting each line of code accomplish more work, through greater abstraction.

Streamlining development
Developers engage in various adjunct activities to coding itself. They design the programs they intend to write; they craft prototypes to prove their designs; they compile or otherwise process code they have written, and they invoke or run programs to test them, often using controlled execution environments (e.g., simulators and debuggers); they integrate their programs with code from other developers; and they package their programs for distribution and deployment.

As code size and complexity increases, each of these tasks (and others) becomes more arduous, especially when using only command-line tools. While numerous tools exist to integrate and accelerate the steps above (e.g., build scripts and make files), the dominant paradigm today streamlines development by integrating the edit/compile/debug cycle (and other steps) through a point-and-click graphical user interface — an integrated development environment.

Graphical IDEs encompass functions that include code browsing and editing, compilation, debugging, and basic project management capabilities. More advanced IDEs provide additional capabilities such as static analysis, performance monitoring, and other tools to enable developers to understand system bottlenecks and use of system resources. Another popular feature built into advanced IDEs is collaborative development support, fostering code sharing among development team members.

IDE market trends
In terms of IDE technology trends, tools for independent software vendors (ISVs) today fall into three major categories. The first includes long-standing suppliers of proprietary development tools who have invested many man-years in building their own integrated environment (e.g., GreenHills Multi, MetroWerks CodeWarrior, and of course Microsoft's ubiquitous VisualStudio product line).

The second group includes companies that create customizations or plug-ins to Microsoft Visual Studio to enable product or application-specific development (e.g., LynuxWorks VisualLynx, Mentor Graphics code|lab, and Texas Instruments CodeComposer Studio).

The third, newest, and most dynamic ISV IDE strategy is to build on a shared open source code base like the Eclipse Project. Evolved from IBM's WebSphere Developer Studio, Eclipse combines code contributed by IBM and dozens of Open Source community members. The growing list of companies supporting, contributing to and leveraging Eclipse includes Ericsson, HP, IBM, Intel, MontaVista Software, QNX, Samsung, SAP, TimeSys, and many others.

Legacy tools suppliers are increasingly moving from their proprietary IDE bases to the poles of Visual Studio and Eclipse (just as the broader ISV and applications space gravitates towards Microsoft Windows or Open Source Linux). The best example of such migration is Wind River Systems legacy Tornado environment, which the Alameda-based company is replacing with an Eclipse-based offering.

Legacy proprietary IDE suppliers add value through the unique features and functions they build into their products, and retain users through familiarity, ease-of-use, branding, and synergy with companion offerings like OSes (Windows, MacOS, RTOSes), hardware-specificity (TI DSP support), or ties to a larger framework (Mentor Graphics CAE). How then, do multiple Eclipse implementers differentiate their offerings around that Open Source IDE?

First they "do no harm". With market penetration and increasing developer use, programmers will come to expect certain core default behaviors from an Eclipse-based environment (as they do with Visual Studio). Eclipse-based ISVs do not "customize" the IDE; instead, they add value through highly purposed and application-specific plug-ins supported as natural extensions to the common Eclipse look-and-feel and capability set.

For example, MontaVista Software offers its own Eclipse-base IDE, MontaVista DevRocket. MontaVista DevRocket integrates tools into its Eclipse base that enable rapid, automatic building of custom versions of the MontaVista Linux OS for deployment to embedded target systems. The Rational Software division of IBM offers Eclipse plug-ins that bridge to and integrate its ClearCase products. Traditional ISVs like Oracle or IBM leverage Eclipse and other IDEs to enable building and deploying applications for use with their respective Application Server software.

Integrating multiple development functions in a single environment is not a new idea. Short of full-blown IDEs, many single-function tools allow varying degrees of bridging multiple point-tools: smart, extensible code editors (GNU/EMACs, SlickEdit) support compiler and debugger invocation, and many debuggers support point-and-click transition to editing from their source-code displays. Despite the apparent ubiquitousness of their use, there are still Command-Line Interface (CLI) die-hards who label IDE usage as a "quiche-eating" activity (along with programming in VisualBasic or "programming with pictures" paradigms).

The IDE-CLI divide correlates strongly with a number of other factors and trends:

• Recent college graduates (last five to 10 years) learned to program with IDEs and prefer their use.

• Enterprise application development today favors IDEs over CLIs.

• Almost 100 percent of all Microsoft Windows application development occurs in Visual Studio and related IDEs.

• The majority of Java applications development is IDE-based, thanks to tools from IBM, Symantec, Borland, and others.

• Most modern Web programming development leverages IDEs (at least for page composition).

• In the embedded world, systems and firmware developers still prefer command-line interfaces, especially for embedded Linux development. IDEs are however, preferred for SoC code development in conjunction with verification and co-design paradigms.

• Embedded applications-code developers, like their enterprise counterparts, tend to leverage IDEs.

• Linux and other Open Source developers still prefer CLI tools, probably from a decade of CLI-focused history and, until the introduction of Eclipse, because of a fragmented IDE landscape.

• Tools and OS vendors like to market IDEs because they provide an attractive demonstration vehicle and a more palpable, visible asset for licensing than do CLIs.

• Managers like IDEs better than line developers, probably because IDEs offer a neat vision of their team's development process; line engineers like CLIs because they afford more control.

IDE checklist
Not all integrated environments are created equal; integration for its own sake adds little to a positive developer experience. An effective IDE should meet or exceed the quality of the sum of its integrated parts.

First-time IDE users or developers experienced with a particular IDE and making a transition should consider the following:

• Many IDEs are at least partially open. Ensure that you can customize key functions to suit your particular needs, e.g., substituting your favorite editor for the default, invoking a different compiler revision or an entirely different compiler without breaking integration of point-and-click error tracking, and integrating resident revision control tools.

• Some IDEs are host-specific (e.g., Visual Studio runs only on Microsoft Windows workstations). If your team uses a mix of workstation types (Windows, Linux, Solaris) or even different versions of the same host (Windows2000 vs. WindowsXP, Red Hat vs. SuSE Linux, Red Hat 8.0 vs. 9.0, etc.), make sure the IDE supports appropriate activities on each type of workstation.

• No IDE is completely seamless and no IDE vendor is immortal. Ensure that your chosen IDE lets your team members access project components using CLI tools and that project data and code itself can be exported to familiar formats and used with legacy "make" tools.

• Ensure that a new IDE offers a clean migration path either from legacy CLI build paradigms or from formats employed by incumbent environments.

• Coming from a CLI environment, you may find some IDEs exert unexpected control over your development project. For example, some IDEs by default hide intermediate file types (e.g., relocatable object files), forcing you either to find new ways to work or to go outside the IDE to preserve your prior work-flow

• Impressive and attractive IDEs may accomplish the goals of a vendor giving a demo, but take pains to understand how they address your projects and practices. Also, IDEs present themselves as a collection of views, perspectives, or states; transition among these views is often non-intuitive. Built-in documentation with real-use scenarios is essential.

Jacob Lehraum (jlehrbaum@mvista.com) is product manager for development tools and Bill Weinberg (bweinberg@osdl.org) is a technologist at MontaVista Software Inc. (Sunnyvale, Calif.).

See related chart One of many available Eclipse-based IDEs, DevRocket integrates tools into its Eclipse base that enable rapid, automatic building of custom versions of the MontaVista Linux OS for deployment to embedded target systems.