Ignorance more frequently begets confidence than does knowledge.
–Charles Darwin
Lisp is the language of loveliness. With it a great programmer can make a beautiful, operating thing, a thing organically created and formed through the interaction of a programmer/artist and a medium of expression that happens to execute on a computer.
Taught that programming—or the worse "developing software"—is like a routine engineering activity, many find difficulty seeing writing as a model or even a metaphor for programming. Writing is creative, it is self-expression, it is art, which is to say it isn't a science and unlike science and engineering, it isn't a serious activity. Judgments like this, though, are easiest made by people who don't seriously engage in making both science and art. Art, engineering, and science are—in that order—part of a continuum of finding truth in the world and about ourselves.
Artists make things and have always done so, gathering knowledge. There is sometimes no other purpose for what artists make than the need to embody an artistic statement in some form—perhaps in an artifact or perhaps on paper. When an artist makes something, he or she is drawing on two parts (at least) of the world at the same time: the part that is driving the construction which could be thought of as being within the artist in a sense, and the part that is in the world providing the substances that combine under physical laws to become the artistic artifact. The least bit of artistic knowledge-making is that the artist is, in making the thing, making a map of what is possible and how the physical world relates to the metaphorical, imaginative, and interior worlds of people. And the other extreme is that in trying to make something perhaps grand, the artist is stretching what people know about the world. Even today there is debate about how some artistic structures were made by ancient artists. Artists discover the properties of the world.
Artists who create by writing or producing other representations of what the world is or could be are also laying out a map for how the world could become, and in cases where artists need technological explanations in their stories and myths, scientists and engineers in many cases explore how to build what they were delighted to learn about as children or adults from the dream-makers. For example, in 1587 someone published a set of tall tales about a possibly historical man known as "Faustus" in a book that came to be known as German Faustbuch or Historia von D. Johan Faustus. The Faustbuch was translated and changed by a man known only as "P. F." in 1592 into the English as The History of the Damnable Life and Deserved Death of Doctor John Faustus. In this book Dr. John Faustus rides a wagon pulled by dragons to the sun. And as time went on, engineers and scientists worked on and devised flying machines, as commonplace today as were sailing ships in the 16th century. Is it a coincidence that cellphones look suspiciously like Star Trek communicators? We can see an early fascination with traveling beneath the sea in the story of Jonah and in the legend of Atlantis. Greeks and Romans wrote about diving bells, and so did medieval writers.
As people need or want to do things with materials and the world, people with special skill take the fore and devise or discover how to manipulate the physical world to make those things. To avoid future mistakes, these makers write down rules of thumb, patterns of creation and making, and safety factors as a practical matter. Today we call them engineers. When we think of engineering today we think of carefully planned scientific engineering such as building bridges, where it is a fairly linear though costly and complicated process to go from the planning stage to a completed bridge. We forget the centuries of tinkering with bridge design in prehistoric and ancient times when bridges were gingerly tested as designers searched for principles. Even still, on November 7, 1940, at 11:00AM, the Tacoma Narrows Bridge collapsed from wind-caused vibrations after being open to the public for a few months, showing that even sophisticated engineering techniques—one could even call them contemporary engineering techniques—can fail.†
Nevertheless, engineering knowledge has usually preceded scientific knowledge and often has remained constant while scientific theories about the engineering materials came and went. "Engineers" were able to create sophisticated fires for cooking and metal working using chimneys and other forms of forced oxygen for centuries while scientists flailed from theory to theory. For example, while advanced fire-based engineering was going on in the 6th century BC in Greece, Anaximenes's theory was that the source or nature of the cosmos was aer (air). Aer was constantly in motion. When aer expanded it became aither (ether: bright fiery air as on a clear day); when it expanded further, it became fire. As aer condensed it became clouds; further condensation led to water, ice, earth, and finally rock. Throughout history there have been various theories of what fire was; nevertheless, the chimneys and other artifacts of working with fire remained constant and working properly.
Scientists come along at the end; they take what artists and engineers have found out or dreamed about the world and try to weave a simplified narrative that explains it all. Scientists need to find the small set of facts, conditions, laws, forces, and principles that cause the beautiful complexity we experience. Since Galileo they have agreed to use mathematics as the language of scientific knowledge.
Scientists, though, perhaps because of their desire for accuracy and precision have had the worst luck of all in pinning down the truth of the universe. Philosophers and historians of science have pointed out and speculated on how scientific theories come and go—through refinement, through revolution, or even through anarchy.
As the 20th century proceeded, for example, the theory of quantum mechanics and the expanding plausibility of complexity science threw everything we knew about the world into doubt, rendering many of our best theories approximations at best, or at least opening the door for a new kind of formulation (other than mathematics) for describing the truth about reality.
Perhaps it's because they are the most consistent losers when it comes to understanding the world that we love scientists so much, tell them constantly that they are the only true beacons we have pointing out what is true; we shower them with grants and money for large experiments and take away funding from the arts.
Well, let's look at the more successful branches of human endeavor: art and engineering. I was recently reading about writers and mapmakers. Writers, of course, are among the most imaginative creators of false realities, meaning that they create worlds and characters that are almost like the real thing, but nowhere will we ever find those places or people or circumstances. We might be tempted to call them liars, but even though all the details are in essence not representative of a particular reality, what is contained in their work is essentially true—there may not be a Nick Adams and neither a Big Two-Hearted River in Seney, but Heminway captured something about real life that makes his story not a lie.
A mapmaker, though, is a kind of engineer—designing and creating representations of the real world for a purpose, usually the purpose of understanding the lay of the land or how to get from one place to another. A mapmaker strives for accuracy and precision in representing the geography of the world. Right?
Not really. First, maps of regions of the earth involve some sort of mathematical projection which, unless understood in a way probably few people can, distorts some aspect of reality significantly. The Mercator projection represents constant bearing paths such as sea routes as straight lines, but whereas meridians converge at the poles, in the Mercator projection they are parallel. Further, length and area are not preserved.
If a mapmaker makes a local map, the surrounding areas are left out, as if they don't exist. If the map is a of a political area, it might leave out places important to people living there—especially in gerrymandered political regions.
A mapmaker's skill lies in knowing how much detail to show and where to leave things out or even tell lies. The following is perhaps one of the most useful maps in the world today. It depicts the London underground transportation system—the Tube.
This map is indispensable even while it totally distorts the geography and geometry of London. Using a ruler to measure distances or using a compass to determine headings is useless. Almost all of London is left out. The Thames, for example, more closely resembles heat ducting in a remodeled London warehouse than it does the famous river or any river for that matter.
Perhaps mapmakers are liars, too.
Novelists and especially short story writers—not to mention poets who do it the most—are in the same business. There simply cannot be enough detail in a story to be any sort of accurate representation of the actual world. Many characters in stories apparently don't work, don't eat, don't go to the bathroom, don't pay bills, don't work out, don't shop—in fact, all that they do is what's connected with the story and what we need to know as readers about them. We don't know where some characters live, what their childhoods were like, where they grew up, what they look like, or even sometimes their names. Fictional worlds are partly real, mainly made up, and almost entirely left out. In this, writers' work resembles mapmakers'.
These skills are the skills of guiding—they are the skills of perfecting the presentation of the finished product. For the mapmaker, the available tools include existing maps, computer-aided design tools, and the talent and skill to know what a map is for and how to create one that serves that purpose for human consumption.
In contrast, the writer has only his or her skills; pens, pencils, computers, and paper; and the language—for simplicity let's say it's English—he or she is writing in. The act of creating a good presentation of a story is the act of writing followed by revision. The writer is guided by the many thousands of writers and stories that have come before, the conventions of the culture, and the extensive reading skills the audience can be expected to have.
But neither writing nor mapmaking are simply guiding. Guides need to have knowledge of their landscapes, and such knowledge comes from exploration and discovery.
Obviously gathering the knowledge needed to make a map is discovery—in fact, when asked to list the best known explorers we think of people who have explicitly set out to complete a map, where a map includes everything that is found there—not simply the land and its features but the people, towns, cities, roads, resources, minerals, crops, climate, and local flora and fauna. Christopher Columbus, Ferdinand Magellan, Marco Polo, Lewis and Clark. To explore, one simply goes and observes. To find out what's on the other side of a mountain range, one just goes there; to see what an island has to offer one simply wanders. But these acts of going and wandering require also noticing and noting.
Most of exploration is in the nature of the locally expected: What is on the other side of that hill is likely to be a lot like what's on this side. Only occasionally is the explorer taken totally by surprise, and it is for these times that many explorers live. Similarly for writers: What a writer thinks up in the next minute is likely to be a lot like what is being thought this minute—but not always: Sometimes an idea so initially apparently unrelated pops up that the writer is as surprised as anyone. And that's why writers write.
Richard Hugo, the 20th century poet and writing teacher wrote about the use of triggers in creative work. A trigger is any idea, scene, image, thought, sound, smell, or memory that by its "appearance" in a mind causes that mind to create something. A trigger can end up being a metaphor, a reminder, a stepping stone, an association, or anything that sparks connections to the creative mind. Hugo almost goes so far as saying that all creativity is really just an ability and willingness to take up the thread a trigger provides.
A poem can be said to have two subjects, the initiating or triggering subject, which starts the poem or "causes" the poem to be written, and the real or generated subject, which the poem comes to say or mean, and which is generated or discovered in the poem during the writing. That's not quite right because it suggests that the poet recognizes the real subject. The poet may not be aware of what the real subject is but only [has] some instinctive feeling that the poem is done.
–Richard Hugo, The Triggering Town
Writing, then, can be viewed as two acts put together: the act of discovery and the act of perfecting the presentation. One seems creative and the other analytic, and therefore, it would seem to make sense to separate them, using the best tools for each, maybe even using the best people for each. This is where some of our software methodologists have landed.
But for almost all writers, the act of discovery is mixed up with the act of perfecting the presentation, because the actual words and the need to select and prune act as triggers and forces on the material in ways that can both require more discovery and cause it whether required or not. And so while each writer may always start with an act of discovery and always end with an act of perfecting, the proportion of each type of act and the order in which they appear will be otherwise as varied as possible. We might be able to say that the statistical behavior of writers shows that more acts of discovery take place near the beginning and more acts of perfecting take place at the end, but this is unimportant information for any particular writer. It can be argued that all writing is creative writing, since if one is writing the way one should, one does not know what will be on the page until it is there. Discovery remains the ideal.
–Richard Hugo, The Triggering Town
Writing a beautiful text takes sitting before a medium that one can revise easily, and allowing a combination of flow and revision to take place as the outlines and then the details of the piece come into view. Changes are made as features of the writing emerge—first the noise, then the sense, the force, and then the meaning—and the work of the writer is to continually improve the work until it represents the best words in the best order. Great writing is never accomplished through planning followed by implementation in words, because the nature of the word choices, phrasings, sentence structures, paragraph structures, and narrative structures interact in ways that depend of each other, and the only possible plan that can be made with which a writer can "reason" about the piece is the piece itself.
This is true of all creative making—flow and revision are the essences. Flow is the preferred state of mind for the writer doing discovery. Flow means that there are no barriers between the movement of the mind and the placement of words on the page. When in flow, the writer feels as if he or she is in a vivid and continuous dream in which the relevant parts of the dream flow onto the page.
Revision includes reading material already written and perfecting it as presentation, but as the name suggests, it is more. Discovery is always mixed in with perfecting, because, as Hugo says, "one does not know what will be on the page until it is there." Moreover, revision—when performed courageously—involves determining what to leave out, just as the mapmaker determines what in the real world can remain unmentioned and unrepresented for a map made for a particular purpose.
For many, this will not sound as if I am describing programming—or as some like to put it: software design and implementation. To satisfy the biases of such folks, I will use untypical words and phrases for concepts that have acquired too strict a meaning.
Following the lead of Paul Graham, I will call Lisp a programming medium to distinguish it from languages like Java™ which is a programming language.
Very dynamic languages like Lisp, TCL, and Smalltalk are often used for prototyping. One of the reasons for their success at this is that they are very robust.... Another reason ... is that they don't require you to pin down decisions early on. Java has exactly the opposite property: it forces you to make choices explicitly.
–James Gosling, Java: An Overview
The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you're inadvertently making.
There are, of course, many situations when making change more difficult is the best thing to do: Once a program is perfected, for example, or when it is put into light-maintenance mode. But when we are exploring what to create given a trigger or other impetus—when we are in flow—we need to change things frequently, even while we want the system to be robust in the face of such changes. In fact, most design problems we face in creating software can be resolved only through experimentation with a partially running system. Engineering is and always has been fundamentally such an enterprise, no matter how much we would like it to be more like science than like art. And the reason is that the requirements for a system come not only from the outside in the form of descriptions of behavior useful for the people using it, but also from within the system as it has been constructed, from the interactions of its parts and the interactions of its parts separately with the outside world. That is, requirements emerge from the constructed system which can affect how the system is put together and also what the system does. Furthermore, once a system is working and becomes observable, it becomes a trigger for subsequent improvement. The Wright Brothers' first flying machine likely satisfied all the requirements they placed on it, but they were unwilling to settle for such modest ambitions—and neither was the world—and even today we see the requirements for manned flight expanding as scientific, engineering, and artistic advances are made.
Christopher Alexander spoke of these issues as follows while discussing an initial Bay Area Rapid Transit ticket booth design study he did early in his career:
So it became clear that the free functioning of the system did not purely depend on meeting a set of requirements. It had to do, rather, with the system coming to terms with itself and being in balance with the forces that were generated internal to the system, not in accordance with some arbitrary set of requirements we stated.... What bothered me was that the correct analysis of the ticket booth could not be based purely on one's goals, that there were realities emerging from the center of the system itself and that whether you succeeded or not had to do with whether you created a configuration that was stable with respect to these realities.
–Christopher Alexander
What bothers and surprises me that so many software developers, managers, and thinkers don't appear to understand this point. James Gosling in talking about Java acknowledges that at least the object-oriented notion of late or dynamic binding is important to support shipping new (though constrained) versions of libraries and to make derived classes, but he seems to forget that the malleability of the medium while programming is part of the act of discovery that goes into understanding all the requirements and forces—internal or not—that a system must be designed around.
As a system is implemented and subjected to human use, all sorts of adjustments are required. What some call the "user interface" can undergo radical reformulation when designers watch the system in use. Activities that are possible using the system sometimes require significant redesign to make them convenient or unconscious. As people learn what a system does do, they start to imagine what further it could do. This is the ongoing nature of design.
We see it at work in writing as well. As the writer reads what's been written, changes come to mind—improvements based on writing gone awry, better words popping up, imperfections, wrong turns, too much left out, too much detail creating distractions, better approaches, or even better ideas and directions. The acts of discovery and perfecting merge for the writer, and for this to happen it is essential that the medium in which the creation is built be the medium in which it is delivered. No writer could even begin to conceive of using one language for drafting a novel, say, and another to make its final form.
Many writers share drafts with other writers to get more eyes and minds involved. There is a tradition of writers' workshops for helping a writer see what the work really is, to understand how readers will approach it, what will be clear and what obscure. Like the mapmaker, the writer wants to find out how travelers will get on in the newly created world. And at any point, the process of discovery can kick in again.
Like many types of artist, the writer is manipulating during the discovery and perfecting stages the very material that represents the work when complete. In the old days, the manuscript would be retyped or typeset, but not so much anymore. The word "manuscript" itself refers to the (hand written) copy of the work before printing and publication, which the writer constantly revises. But the manuscript—which is constantly worked over—differs from a published work only by finally pinning down decisions like fonts, page breaks, illustrations, and design elements.
The distinction some make between prototyping and software development has vexed me my whole career. I have never seen a version 1.0 of a system that was acceptable. I find that every software group messes with the software up until the very time it's deployed or delivered. At the outset the developers want to get something running as soon as possible—they are interested in leaving things out that are not necessary to the purpose of understanding the internal forces and external reactions affecting what has been built. When prototyping was considered part of the development process, people spoke of prototyping languages or languages good for prototyping as an ideal. Though these times are long past, software developers still need to go through the same steps as prototypers did and for the same reasons, but what these developers are using are delivery languages or languages designed to describe tightly a finished program.
The idea behind a description language is to create the most complete description of a runnable program, primarily for the benefit of a compiler and computer to create an executable version of it that is as efficient as it can be, but sometimes also for readers who will perhaps be enlightened by knowing all the details of the program without having to do a lot of thinking.
I like to think of a program written in one of these languages as a "measured drawing." A measured drawing is a set of plans made by a craftsman of a piece of furniture, for example, which enables an amateur to make an exact copy. Whereas a master craftsman will be able to take a rough drawing or an idea of such a piece and by virtue of his or her expertise make a perfect specimen, an amateur may not be able to make all the joints perfectly and in the perfect positions without having all the dimensions and distances spelled out. Often, a measured drawing requires the craftsman to build a prototype to understand the piece and then a second to make one perfect enough to provide the measurements.
The problem with the idea of using a programming language designed to describe finished programs is that programs are just like poems. Paul Valéry wrote, "a poem is never finished, only abandoned." Developers begin work on a project and deliver it when it seems to work well enough—they abandon it, at least temporarily. And hence the series of released versions: 1.0, 1.1, 1.5, 1.6, 2.0, 2.05, etc. Trying to write a program in manuscript using a finished-program programming language would be like trying to write a poem using a Linotype machine. Perhaps using a Linotype machine and thereby producing a beautiful printed book of poetry is good for readers, critics, and therefore literature, but it doesn't help poets and would make their writing lives intolerable with lousy poetry the result.
The screwed-up way we approach software development is because of what we have done with programming languages. With some exceptions, we have opted for optimizing the description of programs for compilers, computers, and casual human readers over providing programming media. Early on, computers were insanely slow, and so performance was the key characteristic of a system, and performance was easiest to achieve when the language required you to "pin down decisions early on." Because of this, much work was poured into defining such languages and producing excellent compilers for them. Eventually, some of these languages won out over ones more suitable for drafting and exploration both in the commercial world and in academia, and as a result it is politically difficult if not impossible to use these so-called "very dynamic" languages for serious programming and system building.
Interestingly, the results of this optimization are well-described by Hoare's Dictum, often mistakenly attributed to Donald Knuth, which states:
Premature optimization is the root of all evil in programming.
–C. A. R. Hoare
Professor Sir C. A. R. Hoare was referring to the practice of worrying about performance of an algorithm before worrying about correctness, but the dictum can be taken to refer to any design problem where optimization is an eventual concern. In this case, the design problem was to design a usable programming medium that excels at enabling developers and designers to explore and discover, and to continue to enable discovery and exploration once well into the perfecting stage. Instead of waiting until we understood the ramifications of large system design and implementation using computer programming media, we decided to prematurely optimize for performance and optimization. And we got program description (or programming) languages instead—the root of all evil.
We can tell this analysis is correct by observing the current fad of Agile methodologies including Extreme Programming. These methodologies all emphasize practices in which code is delivered early in order to enable exploring the design space in the presence of the forces generated by the system itself. As the process continues, the system grows and matures in the context of both internal (system-derived) and external forces.
And we can tell that program description languages have taken the field by observing that very dynamic languages like Smalltalk and Lisp have faded into the background.
Lisp is a medium for working with a computation until it is in balance with its external and internal requirements. At that point it can be decorated with performance-enhancing declarations and perhaps additionally modularized. In this it is more like an artist's medium than what many think of as a programming language.
Lisp, viewed this way, is a good vehicle for understanding how programming and software development really take place. Because programming Lisp is more like writing than like describing algorithms, it fits with how people work better than the alternatives. The problem, of course, is that writing is considered a "creative" activity, involving "self-expression," and creativity is a gift while self-expression is hokey. Not so:
The conventional wisdom here is that while "craft" can be taught, "art" remains a magical gift bestowed only by the gods. Not so. In large measure becoming an artist consists of learning to accept yourself, which makes your work personal, and in following your own voice, which makes your work distinctive. Clearly these qualities can be nurtured by others.... Even talent is rarely distinguishable, over the long run, from perseverance and lots of hard work.
–David Bayles & Ted Orland, Art & Fear
Writing and programming are creative acts, yet we've tried to label programming as engineering (as if engineering weren't creative). Instead of fearing creativity, we need to embrace it.
Moreover, the key to exploratory programming is to be open to triggers and what we happen upon, because the balance a great system needs is not from purely external considerations. It is ok to have been wrong in one's assumptions as long as one is willing to change and revise. In the end one may need to become more of a guide than an explorer, but one must always be open to being an explorer.
Lisp, of course, and especially Common Lisp are my languages. Not since the 1960s have I programmed professionally in a language other than Lisp. Sure, some of that was when I was doing AI research, but most of it was writing system software such as the commercial implementations of Common Lisp my company, Lucid, Inc., produced in the 1980s and early 1990s. I worked on programming environments, debuggers, compilers, memory managers, assemblers, and language extensions. In many cases I was exploring what could be achieved with the goal of productizing the results when the ideas were proved out. Just as I explored the ideas in this essay before revising and polishing it.
Perhaps it's the coincidence of the same mind apprehending different things, but I used to describe AI as "trying to program what cannot be programmed," and I currently define poetry as "trying to say what cannot be said."
In 1995 I decided to return to school and get an Master of Fine Arts in creative writing (poetry) at a low-residency program where most of the work is done at home with only one 10-day residency per semester. At that time, Lucid had been out of business for only a year, and Lisp-based systems had been winning various software-of-the-year awards. I had been consulting at a company that was doing a Lisp-based product, but they were exploring other implementation languages for business reasons.
The school I attended was Warren Wilson College, which is located in Swannanoa in the western part of North Carolina in the Blue Ridge Mountains. It is a small school with a world-class writing program. One of the quaint things about the school is that it has a working farm students are expected to work. The writing world is different from the computing world in many ways, and soon I was immersed in learning how to write poetry. Because I had never had a literature background, I needed to do a lot of catching up, so I spent about 60 hours a week working on schoolwork. I was lucky to find a position as a consultant to Bill Joy on a couple of small projects, and he essentially subsidized me for 2 years learning to write.
When I graduated in 1998, I expected to come back to computing to support myself, preferably by doing research. I had made my 25-year career in Lisp, starting the Common Lisp effort, helping design CLOS, doing research in programming environments, compilation, and parallel languages. I thought that though Lisp might not have a great commercial future, university and industry labs would still recognize Lisp as a viable research vehicle.
I was shocked to learn that I was wrong. As examples, the scientific journal Guy Steele and I founded called Lisp and Symbolic Computation (LASC) had been renamed Higher-Order and Symbolic Computation (HOSC), and my primary scientific conference called Lisp and Functional Programming (L&FP) had been renamed the International Conference on Functional Programming (ICFP). I was discouraged for two reasons. One was that during the 1980s when functional programming researchers had few outlets, many of us Lispers kept the lights on at L&FP for them, and later when Lisp was on the decline, they shut the door. And the other is that this seemed to signal that my field of inquiry had been deleted by the academy.
Now, 5 years later, things are no better even though we face a crisis in computing wherein we cannot build the sorts of systems we need because we as a discipline have embraced a philosophy of inflexibility as part of a fear of large systems when in fact the opposite philosophy is needed. As Jaron Lanier points out, we have not taken seriously the idea that a system or module should be liberal in trying to accept commands or arguments, in trying to understand what the caller wanted done. As Jon Postel remarked:
In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.
–Jon Postel, RFC 791
This is a statement about flexibility, about keeping a system in balance. The perfect bridge is not perfectly rigid, nor is the perfect building. Rigidity works when nothing moves or changes. Flexibility is required when the ground is prone to shake or the wind to blow. Had Web browsers required perfectly formed HTML from the outset, there would not have been the Web. But they were designed to encounter and deal with almost anything that came along.
Discouraged by having no computing career and lamenting static thinking, I was originally heartened by the rising importance of XML—which amounts to some fundamental Lisp data structures reinterpreted by people with bad taste brainwashed by inflexibility. When I mentioned to some programmers that it might be a good idea for a program receiving XML to use pattern recognition techniques like the ones we used in the old AI days to try to understand what the XML was trying to say, they scrunched their faces as if I had told them that poetry is as true as any scientific theory.
I'm glad to see a new book on Lisp. I'm glad there are starting to be some highly innovative conferences on new thinking about computing. And finally I'm glad to see some projects that are throwing off the shackles of inflexible programming: autonomic computing, organic computing, phenotropic computing, acceptability-oriented computing, and the Feyerabend project.
I believe William Stafford captured best what programming is, especially using Lisp, when he defined art this way:
Art is a reckless encounter with whatever comes along.
–William Stafford, Writing the Australian Crawl
† Since I wrote this I found two other more contemporary failures worth noting: the Millennium Bridge in London, which opened June 10, 2000 and closed on June 12, 2000 after enduring unexpected swaying and wobbling; and the new terminal at the Charles de Gaulle airport in Paris, whose roof collapsed on May 23rd 2004 shortly after opening.
The Millenium Bridge was a surprising failure given the high profile of the project and the reputations of the designers and engineering firms involved. Software pundits are sometimes fond of using bridge engineering as an exemplar that software engineering should mimic.
The design of the bridge was decided by a competition organised in 1996 by Southwark council. The winning entry was a innovative “blade of light” effort from Arup, Foster and Partners and Sir Anthony Caro. Due to height restrictions, and to improve the view, the bridge’s suspension design had the supporting cables below the deck level, giving a very shallow profile. The bridge has two river piers and is made of three main sections of 81m, 144m and 108m (North to South) with a total structure length of 325m; the aluminum deck is 4m wide.
Construction began in late 1998 with the main works beginning on April 28, 1999 by Monberg Thorsen and McAlpine. The bridge was completed at a cost of £18.2m (£2.2m over budget) and opened on June 10, 2000 (2 months late) but unexpected lateral vibration (resonant structural response) caused the bridge to be closed on June 12 for modifications. The movements were produced by the sheer numbers of pedestrians (90,000 users [[ Note the use of the term.]] in the first day, with up to 2,000 on the bridge at any one time). The initial small vibrations encouraged the users to walk in synchronization with the sway, increasing the effect. This swaying motion earned it the nickname the Wobbly Bridge.
Resonant vibrational modes have been well understood in bridge designs following the failure of the Tacoma Narrows Bridge. However this was the first time a bridge had displayed this type of pedestrian excited lateral motion. As such the motion was not anticipated by the computational analysis of the bridge prior to construction. It is often thought that the unusually low profile of the suspension cables contributed to the problem, but an analysis by the structural engineer, Arup, shows that it can occur in any suspension bridge which happens to have the appropriate resonant frequencies. After extensive analysis, the problem was fixed by the retrofitting of 37 fluid-viscous dampers (energy dissipating) to control horizontal movement and 52 tuned mass dampers (inertial) to control vertical movement. This took from May 2001 to January 2002 and cost £5m. After a period of testing the bridge was successfully re-opened on February 22, 2002.
–http://en.wikipedia.org/wiki/London_Millennium_Bridge
Some architectural failures are the result of a set of small design and construction problems which combine to tragic results:
Terminal 2E, with a daring design and wide open spaces, was CDG's newest addition. However, on 23 May 2004, not long after its inauguration, a portion of Terminal 2’s ceiling collapsed early in the day, near Gate E50, killing four people. Terminal 2E had been inaugurated in 2003 after some delays in construction and was also designed by Paul Andreu. Administrative and judicial enquiries were started. Coincidentally, Andreu had also designed Terminal 3 at Dubai International Airport, which collapsed while under construction on September 28, 2004.
In February 2005, the results from the administrative enquiry were published. The experts pointed out that the there existed no single fault, but rather a multiplicity of causes to the collapse, in a design that had little margins of safety. According to them, the concrete vaulted roof was not resilient enough and had been pierced by metallic pillars; and some openings weakened the structure. Sources close to the enquiry also disclosed that the whole building chain had worked as close to the limits as possible, so as to reduce costs. Paul Andreu denounced the building companies for having not correctly prepared the reinforced concrete.
On March 17, 2005, ADP decided to tear down and rebuild the whole part of Terminal 2E (the “jetty”) of which a section had collapsed, at a cost of approximately €100 million.
–http://en.wikipedia.org/wiki/Charles_de_Gaulle_International_Airport
[[In 2003 I wrote a foreword for "Successful Lisp: How to Understand and Use Common Lisp," by David B. Lamkins. This essay is that foreword.]]