It's good to be back from a long hiatus, during which time I made a foray into the surreal world of startup software development. Having one's heart, soul and mind in the throes of everyday development makes it difficult to dedicate time to the kind of reflection good writing requires. It's good to be back.

Today's topic is an old one: multi-paradigm design. My book Multi-paradigm Design for C++ first appeared in October 1998. It was a distillation of ideas that emerged from the Software Production Research department at Bell Labs where I had been working on C++ and object-oriented programming, when a new boss named Dave Weiss brought a domain analysis agenda to the department. As a software design researcher, I took an interest in Dave's ideas. My interest became a project when Dave's boss, the well-known Bell Labs manager Sandy Fraser, challenged me to find a way to combine Dave's work with mine. Multi-paradigm design was the answer.

Multi-paradigm Design was a refinement and broad elaboration of notions that go back to the earliest days of the C++ programming language. One-time Dane Bjarne Stroustrup has never called C++ an "object-oriented programming language," and has noted on occasion that if you want to use Smalltalk, then you should use Smalltalk: Smalltalk is the best Smalltalk there is. That good design takes taste, insight, experience, and a rich toolset was one of his more closely held sentiments. He would occasionally use the phrase "multiple paradigms." And when I organized a panel several years ago with panelists including fellow Dane Ole Lehrman Madsen, he noted that Beta is a language that "transcends paradigms." Hmmm, maybe it's a Danish thing. Anyhow, these ideas begged exploration and expression, and a good part of my career took up this endeavor.

The work took shape, honed by workshops and lectures. One of the earliest lectures was given at a conference in Boston in 1993, and the work already constituted a well-rehashed set of concepts at that time. Since then I have published a handful of papers on the topic, and the book (which was an outgrowth of the original 1993 lectures) eventually appeared in English in late 1998. Since then the book has also appeared in Japanese (マルチパラダイムデザ インと C++における実装), Chinese (译者：鄢爱兰周辉), and Russian (МУЛЬТИПАРАДИГМЕННОЕ ПРОЕКТИРОВАНИЕ ДЛЯ C++).

Briefly, multi-paradigm design (MPD) is this:

1. Let your intuition guide the formation of groupings, called families, in the problem domain.
2. Find out what is common among family members; for example, they may all share the same structure and behaviour.
3. Parameterize how the family members vary; for example, they may all vary in the algorithms they use to implement certain behaviours.
4. See if some available implementation technique nicely expresses the commonality/variability association you found for each of the given domains. For example, the object paradigm is very good at expressing commonality in behaviour and variation in each behaviour's algorithms (inheritance and virtual functions), while templates are great to express commonality in code that must be parameterized with some value or type.
5. Frame out the structure, and code it up.

This is different than using "object-oriented analysis" -- whatever that is -- that might prejudice the analysis with premature design partitioning. It allows one to come to object-oriented design honestly and offers strong cues about where templates, overloading, and other C++ goodies apply. And it's not only for C++. It's just that having a richly expressive language makes the transition from domain analysis to coding easier, and C++ was one of the few languages back in the early 1990s that offered such expressiveness; Ada was potentially another. Java as we know it today supports most such expressiveness, as does the C# programming language that has since come onto the scene.

In this 'blog I'll ask you to puzzle with me over why there seems to be renewed interest in multi-paradigm ideas these days after more than a decade of disinterest and, sometimes, outright criticism or even dismissal of such notions.

Mixed Reviews

The bottom line is that the book sales were flat, it was hard to find industrial application of its ideas, and educators didn't touch it with a ten-foot pointer.

Back to the Future

The second and most elaborated review came in a 'blog from Darren Wesemann at Sungard. SunGard is a $4 billion software house that extensively employs what they call a Common Services Architecture, which is a method and architecture based extensively on reusable components. The 'blog describes how MPD is a central underpinning of their overall development framework.

This post was particularly important for me. While I had seen MPD work in the small many times over the years, and while I still think it's a good model for how great programmers actually think about programming in C++ without being conscious of it, I had uncovered few enterprise-scale applications of MPD techniques. Neil Harrison and I had often discussed the relative failure of domain engineering techniques; the ideas look good on paper, but they seemed always to fall victim to unevenness in the scope and scale of parameters of variation within a given domain. People want to enumerate all variabilities in the same basket without pausing to think about scoping them, or about how to ascribe the right variabilities to the right abstractions. Most analysts mix parameters of variation from several domains into a single pot, failing to build on even the degree of domain knowledge they possess.

I sent Darren's 'blog to my colleague Theo D'Hondt. I was Theo's Ph.D. student from 1997 to 2000, during which time I both expanded and significantly refined the MPD concepts. I whimsically pointed out that Darren's post provided evidence that University research indeed had industrial benefits. Theo responded by saying that VUB was considering starting a "largish" program centered on variability in software development. So yet a third advance on the MPD front.

The fourth and final sign of encouragement came from my friend Trygve Reenskaug. Trygve is best known for his early work on object-oriented programming and in particular for having raised the importance of roles as an organizing design principle. Out of this work on roles came the famous Model-View-Controller architecture, as well as his OORAM method as described in his great book Working with Objects: the OORAM Software Engineering Method that discusses object-oriented programming instead of this class-oriented programming about which one hears so much (see my 'blog on this topic and Trygve's follow-up comments). I hold him in awe, and what he says means much to me. I just got a short mail from Trygve on June 30 that said nothing more than:

Hi,
Been reading "Multi-Paradigm Design for C++". A truly impressive and
scholarly work!

Cheers
--Trygve

So after thirteen years of skepticism and marginalization, MPD is suddenly coming into some limelight. Does this mean that MPD is maybe not a niche idea after all? And if that's so, what is going on in the world now that such notoriety should start to blossom?

Whither Thirteen Years?

It was thirteen years ago that I made that first MPD presentation at the OBJEX conference in Boston. Thirteen years is an eternity in Internet years. What explains the potential newfound interest in MPD and the long gestation period?

I'd be interested in 'blog readers' thoughts on this. Please add your comments below. In the mean time I'd like to explore three possibilities: that it didn't market itself as a miracle cure, that it hit an optimally bad point in the world economy curve, and that there just might be a necessarily fixed gestation period for new ideas.

Sex Sells

Multi-paradigm design followed no real bandwagon of the time; it was a loner. And it was a loner not pretending to offer miracle cures. Object orientation had promised productivity and reuse; component-oriented programming had later offered the same; CORBA was to offer the miracle of transparent distribution. Promising to do the impossible (none of these technologies ever delivered on their claim -- read here about the failure of CORBA) gained mindshare. It is not necessary to have a great product for it to sell; only that people believe it could be a great product. Sex sells, and it has become increasingly important to be sexy in software.

If MPD fit any emerging design category, it would be domain engineering -- which at the time was relegated largely to large military projects that lived in the shadows of object-oriented stuff. It was old hat, dating back to the 1970s. No sane opportunist would trace the roots of their key ideas back to that era -- one would be perceived as way behind the curve or as a fool. Ever trying to avoid being the opportunist, I really didn't care, and I could see the value of the techniques. In the book's preface I say: "I never considered titles containing the words pattern, object, CORBA, component, or Java."

The Generative Programming book by Ulrich Eisenecker and Krzysztof Czarnecki was one of the few popular books whose roots go back to an MPD seminar I gave in Germany in the early 1990s, that Ulrich attended, and that moved him to broaden beyond object orientation to deepen the foundations of what we know as Generative Programming today; much of the work was taken up by his student Krzysztof. A whole generative movement and conference series ensued, but it never took on the same proportions as objects, patterns, or components had ever achieved. It wasn't sex, and a lot of people didn't find it pretty.

One of the first things you learn in marketing is that sex sells, and in this era of object-oriented sexiness Domain Engineering looked like a wrinkled 80-year old. Indeed the entire software industry is driven by novelty. In MPD, the ties to C++ were novel, but C++ itself had already been around for a decade. The design technique was powerful and the translation from design to implementation was novel, but there was simply no way to make it fit Rose or Software Through Pictures, the big draws of the time. As such, it sat alone, unheralded by other works because of their ideological remoteness.

Instead, MPD is a technique of first principles. It is not the only set of consistent, broad principles of design that one can imagine, and indeed other systems of design are equally tractable as foundations for learning. But it is a fairly simple and straightforward way of thinking about design that, while eschewing the buzzwords, easily can be reconciled with the deepest principles of OOA, OOD, the GoF "patterns," and of course domain engineering. Even better, MPD provided an integrative framework that showed the relationship between these perspectives. That's systems thinking: thinking about relationships between basic concepts from diverse viewpoints. It is difficult to appreciate MPD without having lived through a few life cycles of a large system, during which time one comes to learn MPD principles the hard way.

One reason that sex sells is its universality: everyone feels they know what it is. (There is the old joke that OOP is like teenage sex: everything thinks they discovered it, and that they do it well, but the reality is otherwise.) If something is outside the comfort zone of the buzzwords of the day, it means that not many people are doing it. That makes it appear risky. Managers want not only low risk but would also be happy with a miracle or two. That's why people who say "Analysis and Implementation Cannot be Unified" will never be listened to. (By the way, what the title says is wrong, but everything in the article is right.)

Last, MPD is open-ended. It is not a methodology or a religion, and is designed to be "universal" in a way so it can accommodate a large spectrum of programming languages and lower-level design techniques (such as object orientation). Open-ended techniques make people suspicious because they are easily led to believe that generality and leverage are mutually exclusive. The cool thing about MPD is that it powerfully spans the entire spectrum of analysis, design, and programming -- programming at the very lowest level. Yet it is suggestive rather than prescriptive. It is, to my mind, everything that a software guideline should be. I think that part of the problem is that people -- or their managers -- want something more prescriptive. If you look at the ideas that have gained mindshare in our industry in the past years (which is not the same as the ideas that were successful) they have a high control component. Extreme Programming -- one of the highest ceremony methods in existence -- is more popular than SCRUM for this reason. C++ (with its compile-time type system) was more popular than Smalltalk (which put more of the power of the type system in the hands of the programmer) for this reason. And object-oriented design (which stubbornly insisted on reducing all design constructs to objects) overshadowed MPD (which was viewed as being more laissez-faire).

Design Method and Economics

I was discussing the renewed interest in MPD with Gertrud Bjørnvig, asking: why now? She asked what year the work first appeared, and I told her. She conjectures that work that appears during an economic downturn will always be investigated for conformity to the status quo: people are risk-averse in economically hard times. The first presentation of MPD was in 1993 at the lowest point of European GDP volume in many years (see Figure 2 in this diagram). The book hit the bookshelves in 1998, right in the middle of a slowdown in the world economy. There was an upturn in 2000, but all eyes probably turned to the software ideas that were emerging concurrent with that upturn: it was in 2001 that Stan Lippman would turn from his C++ programming roots to yield to the fashion of C# to publish a primer on the language, and when Alexandrescu would open up the practical world of template programming to the C++ masses through his Modern C++ Design.

Today, with the economic signs stronger than they have been over the past five years, industry is looking to invest a bit more in the future and to take more risks to outpace competition. That might spark the spirit of innovation and exploration which in turn fuels interest in alternative technology.

The Paradigm Shift Lag

I have often heard it said (but strangely enough, cannot track down an authoritative citation) that it takes a great idea 13 years to reach adoption after it is first introduced. Maybe the source was David Wheeler at AT&T, who used to maintain that it took an idea 15 years from the time it appeared in a research lab until it became mainstream. Such seems to have been the case with object-oriented programming (Simula in 1967; Smalltalk '80 in 1980), automatic transmissions (first introduced by Oldsmobile in 1940 but not common until the 1950s), and many others. (I'd be interested in hearing about more that you can find.) Maybe this corresponds to the time it takes an old generation to die out, or to be displaced far enough by early adapters of a new technology that it overtakes the inertia of earlier technologies.

From its "coming out" in 1993 to the present day is also about 13 years. Perhaps this wine's time has come, and that we're seeing echoes of it across the board. I'll stand up and take a risk here by saying that C++ had a remarkably prescient view of software design. In a course Tom Cargill designed for Technology Exchange Corporation -- Addison-Wesley's teaching arm back in the 1980s -- he showed how most languages of the time were in fact slowly converging on a relatively stable C++ worldview. Maybe this trend has since converged and yielded to another (it's hard to argue that Python fits this model, for example -- and I will say more about Python later) but it was arguably true at the time.

The problem with being great and alone is that you stand alone. No other popular languages of the time featured the expressiveness of C++. Ada was taking a shot at it but would take too long to come to fruition, and died for lack of cultural compatibility with the large C language base out there. Java was far too immature then and C# was still to have its coming out at the turn of the millennium. From a programming language view C++ was culturally compatible with C in an upward-compatible way, but was not ideologically compatible with any other popular language of the time.

Also, in the 1990s -- as has been true in most software design thinking in the industry since the 1980s -- managers believed that one size fits all. UML is a great example of this disease. They were looking for a common design method that would insulate them from changes in technology. The common theme of the day was objects, and the belief (wildly misplaced) that OOD could save you from the pains of migrating from C++ to Java was a major foundation of management religion. To adopt a design strategy that depended on C++ married you to C++, and managers could easily fear such inflexibility wasn't risk-averse enough.

If one looks at a handful of popular languages today, one can argue that Cargill's observation of language convergence has become even more true than he may have predicted. The differences between C#, Java and C++ are much smaller today than were the differences between the main competing languages (Ada, Java, Visual Basic and C++? you decide) in the early 1990s. It is now easier to see, with confidence, how multi-paradigm design transcends the languages of the new millenium. In fact, it was always a broadly applicable technique if you were willing to replace the expressiveness of the C++ type system with some manual discipline, but discipline doesn't sell, either. A design based on MPD would not only survive a language conversion but might help you decide, at the outset, what set of language features (and hence which language) might be best for developing a given product. While such choices were limited at the outset, the development world has slowly converged on this worldview, and viable implementation choices for an MPD design abound.

I have honestly never heard such discussions at an explicit level and doubt that any such rationale has risen to a conscious level of consideration in any project--the Sungard case above being the only exception I know about. Maybe Microsoft has a conscious MPD strategy that one sees reflected in their hybrid combination of languages in the Windows platform; however, such considerations don't really touch the application programmer. Nonetheless, the ideas have been in the air over the past ten years, and that's enough to nudge decisions one way or the other.

The Next Installment