There is an anti-pattern coming to life here, inspired after Visiting Falling Water.
Problem
How do we build functional, beautiful and personal software that the user will want to live in?
We want to put our own personal touch (or body and soul) into the software we build. Software which is characterless is lifeless and uninhabitable.
Customers are often short-sighted about what they think they want. They don't see the problems which they may encounter down the road. They may not understand how the program addresses their domain.
Often, user configurability can make the program a mess. Give the user too much rope and...
Unintentional use of the program can reflect poorly upon the architect. A program may be designed to only work in one particular way, but the customer wants questionable features added that may address problems the program was never meant to solve.
Therefore, (unfortunately)
We build Falling Waters. We build high art that looks good to the user, impresses the user, engages the user and doesn't allow the user to screw it up. We know what is best. After all, we have spent dozens of years building software. How can a neophyte customer know what he wants?
We put a lot of time into building our software to perform its tasks quickly and elegantly. User should feel happy (and perhaps privileged) to use the product of our labors. We will lead them into software nirvana (if they would only let us).
Building software that can grow means that we didn't design it right in the first place. Software Without Ego is software without character.
-- Todd Coram
Comments?
--David Hooker: Falling Water is what you get when you forget the Seven Principles Of Software Development, especially the first, fourth, and fifth. I like this (anti)pattern! Now all I have to say to an errant developer is "That looks like Falling Water to me..."
While looking for a supporting reference for this pattern, I found the following in Richard Gabriel's essay Habitability and Piecemeal Growth (in Patterns Of Software). He writes:
"But a home designed by Frank Lloyd Wright--though more habitable than most "overdesigned" homes--cannot be altered because all its parts are too rigidly designed and built. The needs of the whole have overshadowed the needs of the parts and the needs of the inhabitants."
Though the essay deals with programmer habitability rather than end user habitability, I think Gabriel is largely on point.
The reference I didn't find is from either Alexander or Rybczinski, and speaks to the inverse relationship between architectural awards and habitability. Ring any bells?
-- Dave Smith (10/1/96)
Worse, Falling Water as a home is not a success. The conceit of building it around a waterfall is lovely, but the materials chosen for the rooms do not cope well with the high humidity and the house is a perpetual battleground for mildew and water damage.
One of the reasons that old furniture will reveal strategies for dealing with humidity changes and wood motion is that all the furniture that didn't cope with wood motion has been long since converted into firewood.
-- Ken Meltsner
Apparently, more than one of Wright's designs had problems in practice.
Yes, they did. In his 560 buildings, Wright was pioneering new techniques, using steel and glass in ways no one had ever conceived before, bringing about entirely new ways of thinking about architecture itself (see Organic Architecture). You can't do big things successfully without making big mistakes: Wright's own house, Taliesin, was itself the subject of some of these (under tragic circumstances). Such innovation is an essential Anti Pattern. It's the Anti Pattern that creates new Patterns.
While we usually reserve our praise around here for the immortal Christopher Alexander, if Architecture has anything to teach Software a study of Wright is invaluable. I'm presently reading his "The Future Of Architecture" with considerable relish -- Peter Merel.
Can anyone suggest any other physical architects whose books or works are worth review by software folk? Put them on Other Architects.
I find End User Habitability to be a very important subject. Is anybody working on this?
This Anti Pattern wasn't a slam against Wright. Certainly, failure is a large part of innovation. Unfortunately, we develop Cults Of Personalities around large scale innovators such as Wright and Alexander. Somehow, we look at houses such as Falling Water and revel in the artistic statement they make. We also look at Alexander's APatternLanguage and sing its praises: This is the true way to approach architectural design!
There is much to praise Wright for. However, his Falling Water is not a good example of successful architecture. It is, perhaps, a great warning to young architects and software designers alike: Beware the artistic statement(or: Listen to your users).
-- Todd Coram
I disagree. Sometimes We Have To Builda Falling Water to advance the state of the art and show the users not what is best for today, but what is possible for tomorrow. Consider Windows 2.1. It was slow, it was buggy, it was an absolute bear to program to. Programs that ran on it had lifetimes that were best described as Hobbesian - nasty, brutish and short.
Yet, it engaged a lot of people. It gave them a vision of what a PC could do - all of a sudden you didn't need a Mac to get a WIMP interface. Maybe there were possibilities beyond the 80X25 text mode screen... Windows 2.0 was almost a dead end in and of itself. But it lead to Windows 3.1, which was a (nearly) usable system, which engendered Windows 95, 98 and NT.
Remember the words of Solomon "Where there is no vision, the people perish".
BTW, this is closely related to Living Ina Monument.
Customers are often short-sighted about what they think they want.
And we often fail to understand our customer's priorities.
Consider that the customer of Falling Water, Edgar Kaufmann, may have gotten exactly what he wanted. That is, actually living in Falling Water was much further down his list of priorities than was having bragging rights for having a home designed and built by Frank Lloyd Wright.
As an aside, the web site for Ken Burns' PBS documentary on Wright is well worth a visit. www.pbs.org 
-- Dave Smith
Safe art is boring. Daring art is alive and exciting. Safe architecture is boring. Daring architecture can be alive and exciting. But it can also sometimes be a lousy to inhabit. Maybe that is why My House Sucks.
-- Todd Coram
From "The Wright Space: Pattern & Meaning in Frank Lloyed Wright's Houses":
Few houses of equal fame have embodied more conspicuous faults. Many of Wright's plans defy reasonable furniture arrangements, many frustrate even the storage of reasonable and treasured possessions. In many cases, severe problems afflict the architectural fabric: leaking roofs, unserviceable detailing, even structural inadequacies. A number of the houses were over budget to a degree that challenges belief. And, one must add, there were problems of personality as well: it is a matter of record that many of Wright's clients found him arrogant, careless, slow, and misleading, and were not by any means always amused by his temperament. And there are more vague and subjective difficulties [...]
Normally such pervasive problems would finish an architect's career almost before it started. Yet Wright's houses have offered some quality capable not only of transcending their formidable shortcomings but of engendering a uniquely widespread devotion. Something about them, obviously, has more than redeemed their multitudes of sins. [...] among noted architects almost certainly [Wright had a] record number of [domestic clients] by a wide margin. They came to his drawing board in droves, and, having seen through to completion their adventure with him, they were, by and large, ecstatic about what they got. Evidence of this, and not the sole evidence, is that many of these clients subsequently returned to Wright for another house, and sometimes more than one. [...] two houses [...] were bought back again by the same people who had built them and sold them, because they said they could not feel at home in any other. Robert Twombly, a careful and balanced biographer of Wright, notes that "as questionnaires and interviews establish again and again, his clients love their homes, indeed, are more than ordinarily enthusiastic, and leave, if they have to, with considerable reluctance."
It may serve Wright's critics here to consider whether, just perhaps, they're misunderstanding the real criteria that lead people to enjoy an architecture. Cf. Organic Architecture and Why Wiki Works. -- Peter Merel.
The news about Falling Water only keeps getting worse. According to a March 11, 1999 article in the New York Times, Falling Water's cantilever is failing; as of that date, one corner of the house has sagged more than seven inches over the waterfall, and would continue to do so if not stabilized.
Quoted from the article:
"The most surprising thing about Fallingwater's fate is that it could have been prevented. The problem, as Silman and others who have looked at the structure say, isn't age but Wright's failure to put enough steel reinforcing rods into the concrete -- despite strong admonitions to do so.
Wright's reasons for under-reinforcing the structure aren't clear, but appear to be related to his lifelong aversion to being told what to do. Indeed, when Fallingwater's contractor suggested increasing the steel in the building to make it safer, Wright threatened to quit the project."
The article goes on to note that if the contractor had not installed twice as much steel as Wright requested - behind Wright's back, while Wright wasn't on-site - the building would certainly not have survived to 1999.
The parallels to software development should be painfully obvious. Wright had a bad case of Not Invented Here.
The article will be available for one day (free registration required) at
www.nytimes.com
Hmm. Decay is natural. Falling Water lasted a long time, but was there any requirement on the part of the original owner that it last for the ages? Wright built several buildings, most notably the Imperial Hotel, whose purpose and success was to survive extreme environmental challenges. Perhaps Falling Water is intended, like all natural structures, to decay. Of course more likely Wright was just full of it that day... -- Peter Merel
The current (September 2000) issue of Scientific American magazine contains the article The Plan to Save Fallingwater by Robert Silman, the head of the consulting engineering firm that was hired to investigate Fallingwater's structural problems, determine whether they are getting worse, and (if necessary) devise a plan to stabilize it. It's quite illuminating.
Apparently, when the forms were removed after the concrete had dried in the main terrace that's cantilevered over the stream, the builders recorded an immediate 44 millimeter sag. Fallingwater was unstable right from the start, and Silman's structural analysis shows that the stresses on many of the structural components are almost greater than those components can take; there's so little room for error that the house could easily have collapsed at any point since its construction. The article reports that one of Wright's engineers admitted to forgetting about extra steel reinforcement bars required to take tension stresses in the tops of the cantilevers.
Wright was a genius, and as Peter Merel rightly points out, failure is an inevitable companion of big innovations. But it's clear that, in addition to being a towering genius, Wright was amply possessed of the kind of arrogance that we need to avoid as software developers. To my mind, Todd's Anti Pattern is right on the money. -- Glenn Vanderburg
Of course, in some ideal world, we write all our software ourselves, for ourselves, and can put in whatever oddities we like. If someone looking over our shoulder says "whoa, what's that you're using?" we just smile and toss them a copy of the source. "Here," we say, "find your own waterfall; this is a clue as to what I did with mine."
Daydreaming, -- David Chess
As a possible force to this Anti Pattern:
Designers often feel like being dictatorial to users because users often don't know what they want. This isn't due to user stupidity; it's simply because the cultural memory of how to use these things has vanished.
Regarding the world of physical architecture, Christopher Alexander makes the point that the professionalization of architecture as an academic discipline caused this: People left the craft of building to professionals, and they forgot how to do it for themselves.
But in the world of software, the cause is the opposite: The field is nascent, not decadent. Computer tools have not been around long enough for societies to develop cultural memories of usage & customization, so designers feel inclined to adjust by over-specifying. Hopefully, this will be less necessary in the future.
Humm... this is a very interesting discussion. I went to school to become an Architect, but changed after four and one-half years to software. I am also one who appreciates the "form" that Wright used; however, after visiting the site myself, I agree that there were many basic design flaws... flaws that we software developers mimic. For example, when building software, most of us "plow through." We get an idea and just build it. Then, we do some kind of "force-feed proof of concept" to the client. If we put enough "wiz bangs" in it most clients will accept the product merely from a "wow" affect, and not because the product is functionally sound.
So... what is the balance between form and function? That is the real question here. And who should determine where that balance should be? Also, can the balance shift depending on the client?
My proposal, though it may seem radical, is that we talk to the client and ask him/her/they what they want. Interface with them throughout the DESIGN AND BUILD. Then, when the package is done, it is truly what the customer wanted.
I also believe that the balance between form and function may shift somewhat, depending on what the customer wants. Some clients may really want a product that is more �artsy� and not care as much about its overall functionality. Other clients may care more about its functionality and not as much how the product looks. We, software designers, are not islands. And, until we begin to look at software design differently we will continue to build software that does not represent a �Wright� or �van der Rohe.� Most of the software that comes out of our current way of thinking is neither functional nor formed. It is some kind of chaotic mess that our clients (end users) love to hate. -- John Harper jmharper@nuskin.com
Category Anti Pattern
See original on c2.com