Fortune 500 Technology Manufacturer Uses Eiffel Software to Dominate its Market

Abstract

A Fortune 500 manufacturer of high-end data storage equipment was attempting to bring a new, company-critical product family to market. As is often the case, time and other resources were limited, and the issues were many, technical and otherwise.

The company chose to develop the core application in the Eiffel programming language, using the compiler and tools from Eiffel Software. In the end, Eiffel proved to be an excellent choice, enabling a chronically understaffed team to deliver very ambitious, high quality components and products that in turn provided the foundation for their end-product to achieve market dominance.

Key Results

Solved their most difficult engineering challenges
Realized productivity gains of 10-20x relative to their non-Eiffel teams
Established company as the highest-reliability supplier in their marketplace
Revenues for the Eiffel-related product line grew from zero to over $1 billion in 7 years.

Background

While the company had a mainstream product that continued to be successful, it was clear that the market was evolving rapidly and a new family of products, quite different from their existing line, would be critical to the company’s long-term success. The product required a range of software components from embedded systems to PC-based applications, and everything in between. The components in the middle of the range (the core) made up most of the system’s logic and included configuration databases, commands and rule sets. System consistency was enforced at this level, and implemented in the embedded components.

For this “core” application and for the user-visible parts, the team chose the Eiffel programming language, using the compiler and tools from Eiffel Software.

The team chose Eiffel for a number of reasons. The Eiffel language has many features that map directly to the problem domain, ensure product quality, and enable code efficiency and reusability. Eiffel Software in particular offered significant benefits in the form of high quality libraries and a very productive development environment. The team also included a couple of individuals with prior exposure to Eiffel, and their experience had told them that Eiffel was by far the best tool for such a large, critical set of applications that demanded high quality.

In the products developed, there are three fundamental component sets: the “muscle” or embedded components, which compute and manipulate data; the “brains” or configuration, command and rule systems; and the “face” or user-visible applications. Eiffel is presently used in both the configuration/command/rule components and user-visible components (the brains and the face if you will).
The embedded software is written in C++ and a small amount of assembly language. Those components are disk-based and their development tools are pretty much industry standard. The technical lead reported: “There are no special hardships associated with development of those components (other than the fact that they are developed in C++ and assembler), though they do lack a high-end IDE. The Eiffel software components were quite ambitious, characterized by significant logical and functional complexity. Some of the trickier problems and challenges involved dealing effectively with the often very complex internal data relationships.”

Technical Requirements and Observations

The first product requirement (and technical challenge) was one of reliability, measured in terms of equipment availability. The company’s products had an expectation of “six nines”, or 99.9999% availability – equivalent to unplanned downtime measurable in seconds per year (if any). Every component, hardware or software, had to be designed with the customers’ business continuity in mind. This strictly mandated correctness in the software. The Eiffel components, as the decision-making and rule-enforcing agents, had to be especially disciplined. This requirement was in fact a key factor for selecting Eiffel in the first place. Management’s earlier experiences with Eiffel had taught them that Eiffel’s Design by Contract™ feature and comprehensive support for object-oriented software engineering would enable them to create systems that lived up to customer expectations.

The second major technical requirement was to ensure that the relationships between all logical components were never corrupted. Ensuring this with the complexity of the hardware/software configuration again virtually mandated using the assertion mechanisms that are found only in Eiffel. In practice, the Eiffel assertion mechanisms proved invaluable in this area. The assertions provided run-time verification of the specifications, and in fact provided the specifications themselves (as is the case with all good Eiffel code).

A third, rather challenging requirement was to detect and correct any errors that might occur elsewhere in the system. Without total confidence in the logic built atop the Eiffel components, such requirements would have been impossible to satisfy.

For reference, the two largest Eiffel applications in this product configuration contained about 800 and 2000 classes respectively, with millions of active objects at a given instant.

Included in the software were a few third-party components written in C and C++. These components were chosen for various reasons, and included such capabilities as Secure Socket Layer (SSL) support. Another useful third-party component was a list/grid widget, chosen for its extremely fast repainting performance (at times, displays included thousands of items). Eiffel provided a safety-net around these components by letting developers wrap the components in proper assertions, forming contracts not otherwise possible in their native languages. This technique helped isolate potential issues with those external components quickly and reliably. To quote the technical leader, “If not for Eiffel, we wouldn’t have known where (else) in the system that the problems were.” He went on to say that having Eiffel and particularly its powerful assertion mechanism has made the whole product better, including components developed by other teams in other languages. This is because the Eiffel assertions exposed flaws in those other areas of the software (and even hardware), and they were then able to identify and address those flaws efficiently.

Bug fixes within the Eiffel-based components were virtually instantaneous. The project’s technical leader attributes this and the extremely low overall bug-rate (see below, in Results) to two possibilities:

Every member of his team is incomprehensibly brilliant; or
His team members would naturally be as likely to create as many bugs as any other team’s developers -– but Eiffel:
- lessens the likelihood that they will create a bug
- encourages better practices and increased self-discipline,
- prevents almost any bug they do create from getting into their system, and
- if a bug gets in, the built-in Eiffel trace mechanism pinpoints the error.

He gave the following comparison: A typical “bad pointer” problem in C would take 2 days to trace and repair. On the other hand, such a problem normally can’t happen in Eiffel (effectively, zero days). In Eiffel, a developer can sometimes neglect to create an object before accessing its features. This kind of problem is routinely found during development itself. If for some reason this indiscretion makes it into the verification cycle, Eiffel will generate a stack trace, with function names and statement numbers that identify the exact point where the error occurs. The testing personnel have grown to expect near-immediate turnaround on any problem they find in the Eiffel code, as they supply the developers the trace when the bug is reported. The fact that Eiffel does not support the notion of address aliasing means that the point of error is often all that is needed to find and repair the original fault.
According to the technical lead, “The only problems you get in Eiffel are logic problems (i.e., problems that you would have in any language because of a flaw in your own thinking). Eiffel helps you to locate and fix those problems though, in a way that no other language does. With Eiffel, the language never gets in the way of the problem being solved, and never becomes the problem itself. With Eiffel, we can focus on the design, work at the design level and even at the model level. The fact is, Eiffel gives us a single language for our design, our model, even our specification, and it just so happens that it compiles into good executable code.”

Organizational Observations

The team working with Eiffel also faced an unexpected organizational challenge. There was little understanding on the part of the embedded component teams of the importance and difficulty of creating the types components that would be done in Eiffel. This was further exacerbated by two factors. First the embedded component development effort was less productive, simply a limitation of the tools available. Their teams were correspondingly much larger, and eventually accounted for nearly 90% of the total development work force for the division. The productivity differences themselves contributed to a somewhat insular or defensive culture.

The second challenge facing the Eiffel team was ironically a result of the efficiency of developing with Eiffel. The team working with Eiffel was so effective at developing their components that the other teams, and even management, began to believe that the components themselves were simply not that big a deal – how could they be? The team was able to deliver even large systems quickly and without functional problems. The differential was difficult to ignore: With only 10% of the programming personnel, the team using Eiffel had produced 40% of the system’s code, and further, was responsible for only 1% of critical problem reports.

One of the lessons gleaned from the experience was that management needs to be involved in the choice of project tools and in fostering good communication and cooperation between groups. They noticed that significant differences in productivity between teams, left un-discussed, were often interpreted as an indictment of the less productive team – when in reality, the productivity differentials were more objectively attributable simply to the difference in tools the groups were using.

Results

The team that used Eiffel out-produced all other teams in virtually every measure of project success: capability delivered over time, speed of integration, stability, and cost of maintenance.

As some of the Eiffel code was responsible for the integrity of the entire system, the Eiffel code was often in the position of preventing or minimizing the negative impact of problems in the other components. As stated earlier, the team using Eiffel, with 10% of the personnel, produced 40% of the system’s capability and yet was responsible for only 1% of critical problem reports. And as a testament to the reusability and extendability of Eiffel systems, in ongoing releases, the Eiffel components typically had zero regressions during qualification.

Some components, in particular the management applications, were developed with 5% to 10% of the total resources needed for equivalent applications from other groups. Put another way, the productivity of the Eiffel developers was between 10 and 20 times that of the developers in the other groups.

These benefits/results derived from a number of factors related to the use of Eiffel, including:

Seamless transitions from conceptual models to implementation. There was no need to redesign to fit the restrictions imposed by a limited implementation language
Comprehensive support for object oriented software engineering.
- Design by Contract
- Full assertion support
- Strong typing
- Full support for polymorphism
Libraries built on the same principles.
Smaller development teams made possible by high leverage and reusability attained using Eiffel.
Simple mechanisms for working with external components in C and C++.
A portable and powerful abstract GUI toolkit (EiffelVision).
Fast and efficient coding and debugging.

Plans for Microsoft .NET Capability

The company is unwilling to discuss their proprietary plans surrounding whether they will move to the .NET framework. However, the team leader was able to say this much: If and when the company chooses to go with a project in .NET, Eiffel will make it a LOT easier – they can reuse virtually all their previous work, and simply recompile to Windows on .NET. If they had used other-language products for their prior projects, they would have had to rewrite it all.

Summary

According to the project’s technical lead, “In software development, you can ‘stack the deck in your favor’ (i.e., increase the probability of success) by putting in place the right people, the process and the tools. I find that, in general, there is a lack of motivation to look at a better way of doing things among developers and their managers. However, in a given organization, there are a number of people who ARE motivated to make the team successful. They analyze what, why and how of developing and problem solving.”

As a result of his and his team’s shared focus on quality and productivity, EiffelStudio is a natural fit for the team’s work. The design process is both driven by Eiffel, and supported by it. The methods heavily employ polymorphism, multiple inheritance, strong typing and uniform references – all features of Eiffel that are not found in other languages. They have grown to expect and demand these capabilities of their tools.

But when asked why Eiffel has increased his team’s efficiency and quality so much, he replies that, “There is no one reason – the compelling motivation is that the Eiffel Development Framework is a comprehensive framework for doing software the right way. This is perhaps the main reason why dabblers often choose more trendy or faddish tools rather than Eiffel – they don’t understand the savings involved in doing it the right way. They are less concerned with the cost and complexity of poor software engineering than they are with a single attractor, a hook. The more sophisticated the analysis, the more compelling the reasons for using Eiffel, but it’s never just one thing – software engineering is after all, a lot more than typing in code at the keyboard. We’re supposed to be paid to think, to consider the big picture, to get it right.”

Each project that the company’s Eiffel team has undertaken in the course of 7 years has been successful. During that time, that division has grown into a $1 billion player, dominating its market segment.

According to the technical leader, if they had used C++, they would have been fighting their own fires, they would be behind on development, their products would not be as reliable, they would be not as strong in the marketplace, and not as nimble and responsive to customer requirements.

“With Eiffel, once you have a non-trivial system, with a reasonable set of business classes, change and nimble-ness are very easy – you simply do a little ‘remodeling’. Reuse most of your classes, perform a little adaptation, and bam! – you’re done. Eiffel helps keep the system flexible, preventing the kind of rigidity and limits we see typically in C++ and Java systems.”

About Eiffel Software

Eiffel Software (a division of ISE) is the world leader in Eiffel true object-oriented programming tools. Founded in 1985, Eiffel Software produces proven professional tools and component libraries for business-critical and enterprise software developments. Eiffel Software’s products enable their clients to output more and higher-quality software in less time than with any other development tools available. Its users span the globe, in industries ranging from large financial institutions and transaction houses, to technology manufacturing, to government and defense contractors, to health care providers and more.