The power of simplicity

May 2005

The best defense against falling prey to technology fashion is to be skeptical of complex solutions. Is the complexity warranted? Sometimes it is, but often it's just a smokescreen to hide the existence of simple and effective answers.

Take the basic idea of object technology: to use the power of software modeling techniques -- essentially, abstract data types -- to describe systems of just any kind. The idea was there from the beginning, and Eiffel took it to its full development thanks to Design by Contract (and multiple inheritance, genericity, deferred classes, Uniform Access, Command-Query Separation...etc). This is a threat to an entire industry that thrives on complexity and incompatibility: if you have different formalisms for thinking, communicating and implementing, then you need consultants and tools to translate between the different levels. Quick (the strategy seems to have been), let's preempt the "object oriented" name -- it sounds cute -- and get back to the old order where the coders coded and the analysts analyzed: we'll use C++ and Java for implementation, so that no ordinary human being can understand the code, and UML for description, so that there is no semantics of any kind. This will give us an entire industry. It will also give us PhD thesis topics, such as trying to define what semantics UML might have.

Then (ten years later) we'll pretend to find out that there is a gap to be filled: new opportunities! New acronyms, for example: "Model Driven Architecture", as if Kristen Nygaard hadn't taught us back in 1970 or so that good programming is modeling in the first place. Modeling, of course, is passé. Today we talk about "metamodeling". (It is a pretty good principle of a blissful life to stop listening whenever you hear a word that starts with "meta". There may be a couple of exceptions but you don't risk much by ignoring them.)

Eiffel protects you from all that waste of time. The idea is simple: the schemes of object technology, originally developed for programming, are in fact schemes for thinking -- about systems, about the world. We use them to tackle complexity and devise robust, extendible architectures. (The architecture doesn't have to be "model-driven": it *is* the model!). Then we turn them into software implementations, smoothly and seamlessly. We don't distinguish between the program and the model of the program: the program is just the model refined to full implementability. We work in a single context from beginning to end, using the same concepts (classes, contracts and all the powerful modeling techniques of object technology), the same notation (Eiffel text, or graphical equivalents to it which can constantly and effortlessly be mapped back and forth), the same software support (EiffelStudio). We don't need to invest in a multitude of tools, and translators between these tools. We need fewer people. And if the external conditions change, we have a much easier job adapting the software, since it's really the same product as the model describing these conditions.

There are very few Three-Letter-Acronyms in all this, and very little that would qualify as "meta". But if you are fed up with pretentious and expensive approaches that leave you dizzy with grandiose phrases and short on actual results, you might try simplicity for a change.

-- Bertrand Meyer