Edsger Wybe Dijkstra (1932-2002) was a mathematician and a pioneer of the computing sciences. He influenced much of the early developments of programming languages, operating systems, formal verification of algorithms, and distributed processing. He is the one who coined the term structured programming back in the late sixties at a time when programming languages where still often considered as a "hardware extension".

EW Dijkstra was a blogger before blogs could ever exist. Indeed, he communicated regularly his research and thoughts under the form of short notes known as EWD's for they were sequentially numbered from EWD1 till EWD1318 and distributed to his "web" of scientific peers using paper, then fax, then email, and are now available on the World Wide Web.

EW Dijkstra was not only producing scientific articles, but also shared his visions on the past, present, and future of his time. Many of these carried a remarkable pertinence and I found in some of them the words I was willing to say in the early 2000's about the field of Enterprise and Application Integration.

Of course in the seventies EW Dijkstra was not talking about Integration itself, but about the developments of Programming as a discipline. However, the transposition is much uncomplicated because the outcome is compelling. Then, instead of plagiarizing his works, I invite you to read the true words of a master. Just think about Integration whenever you read "Programming".

Some meditations on Advanced Programming

[...] In this atmosphere of pioneering, programming has arisen not as a science but as a craft, as an occupation where man, under the pressure of the circumstances was guided more by opportunism than by sound principles. This—I should like to call it "unhygienic"—creativity and shrewdness of the programmers has had a very bad influence on machine designers, for after some time they felt free to include all kinds of curious facilities of doubtful usability, reassuring themselves by their experience that, no matter how crazy a facility they provided, always a more crazy programmer would emerge that would manage to turn it into something profitable—as if this were sufficient justification for its inclusion.
[...] They have concocted thousands and thousands of ingenious tricks but they have given this chaotic contribution without a mechanism to appreciate, to evaluate these tricks, to sort them out. [...] But the tricks were defined in the name of the semi-God "efficiency" and for a long time there was hardly an inkling that there could be anything wrong with tricks.

Programming: from craft to scientific discipline

EW Dijkstra associates the failures of tentative designs for new and better programming languages in the early seventies to a (his words) profounder reason: we did not know the nature of the programmer's task well enough.
[...] For instance the paralyzing stress on the requirement that the new language should be "easy to learn"; in practice this meant that the new language should not be too unfamiliar, and too often "convenient" was confused with "conventional". More and more people began to feel that tuning those designs to the supposed needs of the nonprofessional programmer was ... for lack of any idea how a truly professional programmer would look like!
Further in the article, EW Dijkstra points out another bias onto our designs:
[...] While in the past it was regarded as the purpose of our programs to instruct our computers, a shift to the opposite view could now take place, viz. that it is the purpose of our machines to execute our programs. Or, to put it another way, logic which up to that moment had mostly been a descriptive science, fraught with metaphysics, now also admitted to be regarded as a prescriptive science, almost as a discipline of engineering.

Indeed that is just what happened to Integration: the very last integration vendor solutions give at last some feeling that their designs were no entirely driven by all the technology to tie altogether, but by some idea (although open to improvement) of the integrator's tasks.

Essays on the nature and role of mathematical elegance

In the first essay, EW Dijkstra describes the "lack of elegance" in computing with a rare pertinence, and proposes "elegance" as a criteria worth considering for measuring the quality of works.
[...] We have surrounded ourselves by artefacts of needlessly clumsy designs, which make them cumbersome to develop and to maintain, and dangerous to rely upon; nevertheless they are relied upon, partly because we have the feeling that we have no choice, partly --and that is where I protest-- their imperfections have been raised to the status of a Law of Nature.
[...] it is now quite openly admitted that in the whole process of using computers the limits of our programming ability present a more serious bottleneck than the intrinsic constraints of the hardware, and the efforts to trespass those limits result in systems of incontrollable complexity.
[...] Deep in their hearts the idea of complete intellectual control over their designs does not really attract them: many, I found, derive a great part of their professional excitement from not quite understanding what they are doing and from the glorious risks they take in their daring irresponsibility. Besides that it is very questionable, whether simplicity has any sales value. He who regularly addresses western academic audiences quickly discovers that, on the average, his audience is impressed to the extent it has not understood him: by a perfectly understandable lecture many people in the audience feel somewhat cheated [...]. As a result, most audiences exert on most speakers a pressure—subconscious at both sides—to be occasionally unnecessarily obscure. In analogy, I would not be amazed at all, if the customer exerted a similar pressure on manufacturers of hard- and software, and market has shown that complexity sells better.
In the second essay, he analyses thinking activity and speaks about "reasoning" versus "pondering".

On the Role of Scientific Thought

Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. [...] It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for ordering one's thoughts, that I know of.
[...] But of course any odd collection of scraps of knowledge and an arbitrary bunch of abilities, both of the proper amount, do not constitute a scientific discipline: for the separation to be meaningful, we have also an internal and an external requirement. The internal requirement is one of coherence: the knowledge must support the abilities and the abilities must enable us to improve the knowledge. The external requirement is that of a "thin interface"; the more self-supporting such an intellectual sub-universe, the less detailed the knowledge that its practitioners need about other areas of human endeavor, the greater its viability.
[...] In view of the preceding it becomes quite obvious why many earlier efforts to concoct Computing Science Curricula at our universities have been such dismal failures. They were just cocktails! for lack of other ingredients, they tried to combine scraps of knowledge from the most diverse fields that seems to have some relation to the phenomenon Computer. That the ingredients of the cocktail did not mix into a coherent whole, is not surprising; that the cocktail did not taste too well, is not surprising either.

The end of Computing Science?

In the March 2001 special issue of the Communications of the ACM dedicated to the "next 1000 years" of computing, E.W. Dijkstra dared—amongst a majority of promoters—to raise a voice: "wait a moment! step back a little and consider the whole picture: we are possibly not as far as we claim to be, for computing science has fallen far off our main concerns"
[...] computing has matured from a theoretical topic for the scientists to a practical issue for the engineers, the managers, and the entrepreneurs. This is, mostly people who can accept the application of science for the obvious benefits, but feel rather uncomfortable with its creation because they don't understand what the doing of research, with its intangible goals and its uncertain rewards, entails.
[...] You see, while we all know that un-mastered complexity is at the root of the misery, we do not know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. [...] We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy. We do not know yet whether trade-offs will be possible. We do not know yet whether we can invent for intricacy a meaningful concept about which we can prove theorems that help. To put it bluntly, we simply do not know yet what we should be talking about, but that should not worry us, for it just illustrates what was meant by "intangible goals and uncertain rewards".

Integration Platforms of today

I do not want to stop here on a negative tone. The merit of these essays is to force us to take a distance and open our eyes on where we stand. Indeed, I do think that significant improvements in the integration field are just taking shape. As a matter of fact, major announcements by integration vendors in the last years related to completely redesigned versions of their flagship products. Were the earlier designs too good? Some can advocate that the advent of Web Services imposed a shift in technology and then a rework, but I believe that this is instead the expression of a more fundamental search for better ways to interconnect our application systems. The present craze around Service Oriented Architectures—notwithstanding their true value—looks to me like an overreaction in the hope of having found at last "the" solution to a long series of sloppy integration systems that often left a trail of deep frustration.

History repeats itself. The problems that EW Dijkstra faced with the development of Programming in the seventies illustrate quite well some of the problems we face with Integration nowadays. And as he points out, I'm inclined to believe that we have effectively reached a turning point: one where the platforms stop being piles of technologies equipped with purportedly simplifying interfaces, and become systems designed to support the integrators' works, even—in rare cases still—with bits of consideration for the different roles as integration designer, developer, operator and user.

Taking some distance and despite the considerable progress so far, there is still a long way to go, and much to learn about. That, EW Dijkstra also told us.

[www.artofe.biz] © 2005 bernard Hauzeur • All rights reserved.