The Artima Developer Community
Sponsored Link

The Demand for Software Quality
A Conversation with Bertrand Meyer, Part I
by Bill Venners
October 27, 2003

<<  Page 3 of 3


The Challenge of Complexity

Bill Venners: You said in your book, Object Oriented Software Construction, "The single biggest enemy of reliability and perhaps of software quality in general is complexity." Could you talk a bit about that?

Bertrand Meyer: I think we build in software some of the most complex artifacts that have ever been envisioned by humankind, and in some cases they just overwhelm us. The only way we can build really big and satisfactory systems is to put a hold on complexity, to maintain a grasp on complexity. Something like Windows XP, which is 45 million lines of code or so, is really beyond any single person's ability to comprehend or even imagine. The only way to keep on top of things, the only way to have any hope for a modicum of reliability, is to get rid of unnecessary complexity and tame the remaining complexity through all means possible.

Taming complexity is really fundamental in the Eiffel approach. Eiffel is there really to help people build complex, difficult things. You can certainly build easy or moderately difficult systems using Eiffel better than using other approaches, but where Eiffel really starts to shine is when you have a problem that is more complex than you would like and you have to find some way of taming its complexity. This is where, for example, having some relatively strict rules of object modularity and information hiding is absolutely fundamental. The kinds of things that you find in just about every other approach to circumvent information hiding don't exist in Eiffel. Such strict rules sometimes irritate programmers at first, because they want to do things and they feel they can't, or they have to write a little more code to achieve the result. But the strictness is really a major guard against the catastrophes that start to come up when you're scaling up your design.

For example, in just about every recent object-oriented language, you have the ability, with some restriction, of directly assigning to a field of an object: x.a = 1, where x is an object, a is a field. Everyone who has been exposed to the basics of modern methodology and object technology understands why this is wrong. And then almost everyone says, "Yes, but in many cases I don't care. I know exactly what I'm doing. They are my objects and my classes. I control all the accesses to them, so don't bother me. Don't force me to write a special routine to encapsulate the modification of field a." And on the surface, people are correct. In the short term, on a small scale, it's true. Who cares?

But direct assignment is a typical kind of little problem that takes up a completely new dimension as you start having tens of thousands, hundreds of thousands, or millions of lines of code; thousands or tens of thousands of classes; many people working on the project; the project undergoing many changes, many revisions, and ports to different platforms. This kind of thing, direct assignment of object fields, completely messes up the architecture. So it's a small problem that becomes a huge one.

The problem is small in the sense that fixing it is very easy in the source. You just prohibit, as in Eiffel, any direct access to fields and require that these things be encapsulated in simple procedures that perform the job—procedures which, of course, may then have contracts. So it's really a problem that is quite easy to kill in the bud. But if you don't kill it in the bud, then it grows to a proportion where it can kill you.

Another example is overloading: giving the same name to different operations within the same class. I know this is controversial. People have been brainwashed so much that overloading is a good thing that it is kind of dangerous to go back to the basics and say that it's not a good thing. Again, every recent language has overloading. Their libraries tend to make an orgy of overloading, giving the same name to dozens of different operations. This kind of apparent short-term convenience buys a lot of long-term complexity, because you have to find out in each particular case what exactly is the signature of every variant of an operation. The mechanisms of dynamic binding as they exist in object technology and of course in Eiffel are much more effective than overloading to provide the kind of flexibility that people really want in the end.

So these are examples of cases in which being a little more careful in the language design can make a large contribution to the goal of taming complexity. It's also sometimes why people haven't believed our claims about Eiffel. The use of Eiffel is quite simple, but the examples that we publish are simple not necessarily because the underlying problems are simple, but because the solutions are. Eiffel is really a tool for removing artificial complexity and finding the essential simplicity that often lies below it. What we realize now is that sometimes people just don't believe it. They don't believe in simple solutions. They think we must be either hiding something or that the language and methods don't actually solve the real practical problems of software development, because they know there has to be more complexity there. As this horrible cliche goes, "if it looks too good to be true, then it must not be true," which is certainly the stupidest utterance ever proffered by humankind. This is the kind of cliche we hear from many people, and it's just wrong in the case of Eiffel. If you have the right tools for approaching problems, then you can get rid of unnecessary complexity and find the essential simplicity behind it.

This is the key issue that anyone building a significant system is facing day in and day out: how to organize complexity both by removing unnecessary, artificial, self-imposed complexity, and by organizing what remains of inevitable complexity. This is where the concepts of inheritance, contracts, genericity, object-oriented development in general, and Eiffel in particular, can play a role.

Bill Venners: It sounds to me that you're talking about two things: getting rid of unnecessary complexity and dealing with inherent complexity. I can see that tools, such as object-oriented techniques and languages, can help us deal with inherent complexity. But how can tools help us get rid of self-imposed complexity? What did you mean by "getting at the simplicity behind the complexity?"

Bertrand Meyer: Look at modern operating systems. People bash the complexity of Windows, for example, but I'm not sure the competition is that much better. There's no need for any bashing of any particular vendor, but it's clear that some of these systems are just too messy. A clean, fresh look at some of the issues would result in much better architecture. On the other hand, it's also true that an operating system—be it Windows XP, RedHat Linux, or Solaris—has to deal with Unicode, with providing a user interface in 100 different languages. Especially in the case of Windows, it has to deal with hundreds of thousands of different devices from lots of different manufacturers. This is not a kind of self-inflicted complexity that academics like to criticize. In the real world, we have to deal with requirements that are imposed on us from the outside. So there are two kinds of complexity: inherent complexity, which we have to find ways to deal with through organization, through information hiding, through modularization; and artificial complexity, which we should just get rid of by simplifying the problem.

Next Week

Come back Monday, November 3 for the fifth installment of a conversation with C# creator Anders Hejlsberg If you'd like to receive a brief weekly email announcing new articles at, please subscribe to the Artima Newsletter.

Talk Back!

Have an opinion about the design principles presented in this article? Discuss this article in the News & Ideas Forum topic, The Demand for Software Quality.


Bertrand Meyer is the author of Object-Oriented Software Construction, which is available on at:

Bertrand Meyer's Home Page at ETH, the Swiss Institute of Technology:

The Grand Challenge of Trusted Components, presented by Bertrand Meyer at the International Conference on Software Engineering, May 2003:

The Structure and Interpretation of Computer Programs, by Harold Abelson and Gerald Jay Sussman with Julie Sussman:

Find out more about Eiffel at:

The Eiffel language FAQ:

The 2001 Interview with Programming Expert Bertrand Meyer in InformIT:
(Gratuitously long URL omitted...)

<<  Page 3 of 3

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use