Form And Function Are One

Another of FrankLloydWright's OrganicArchitecture principles. Look at a hand, or a flower, or a wing, or an eye - these things are not mere aggregations of elements, but vitally interdependent mechanisms wbose function cannot be distinguished from their form.

From the OrganicArchitecture page: FORM FOLLOWS FUNCTION is a much abused slogan. Form is predicated by function but, so far as poetic imagination can go with it without destruction, transcends it. Only when we say or write FormAndFunctionAreOne is the slogan significant. It is otherwise the password for sterility.

So how come every form is different, when they are all serving the same function? For example, your retinal prints are different from mine, but we both use eyes for seeing with. In reality. quite a lot of natural forms have random or arbitrary elements. -- DaveHarris

But isn't it interesting that the arbitrary elements are tangential to the aspect of form which serves the function. Fingerprint patterns are differentiated, yet they provide the common function of providing a frictional pad for our digits.

I tend to think that variation in nature occurs where it is tolerated by function and we will see the most variation in areas where function shields it. Um, will anyone think I'm too weird in calling this an instance of the ShieldPattern?? DavidLynch? talks about fast areas and slow areas in the visual aspects of nature. But, I'm not sure that software would survive the application of Lynchian philosophy. We'd start to search for patterns in haphazard arrangement of meal leftovers and software documentation. --MichaelFeathers

All instances of forms have variations; it's really a value judgement to identify any two processes as being in the same bucket (more subjectivism per LaoTse). Nevertheless when we look at building classes it serves us well to factor out both function that does not follow form and form that does not follow function.

An example of the former might be, say, a collection class with an embedded iterator. The obvious benefit being that by refactoring it becomes safe to write multiple routines that iterate the class. An example of the latter might be applying a reflective architecture pattern to some very simple problem domain - something where a BallOfMud? http://www.laputan.org/mud/mud.html architecture would work fine. YouArentGonnaNeedIt after all.

For me, when FormAndFunctionAreOne elegance has been maximized. By maximizing elegance you minimize maintenance hassles and extraneous documentation, and improve the longevity of the work. The obvious case in point is the wikibase itself.

-- PeterMerel.

I don't really disagree with that. I was struck by the assertion to the effect that mere "form follows function" is a password to sterility. The reference to poetry doesn't help. He's apparently getting at some difference between the two phrases, but I haven't nailed down exactly what in a way which matches my own image of nature.

In Alexander's work, variations in form are often driven by variations in circumstance. Everything is customised and de-massified. (For me this stuff relates to TheThirdWave book.) Thus it might be appropriate to embed an iterator into a collection class if that is what the moment demands. Another example is the IntrusiveList?. The "function" in this case includes low-level efficiency: the aesthetic of efficiency overrides more academic notions of elegance or modularity.

I have trouble reconciling his ideas on buildings with computer software. Would he be happy with the various ways we have to parameterise classes, or would be prefer every routine to be hand-crafted? -- DaveHarris

I confess I've only skimmed TheThirdWave, so shan't comment there. But what I think Wright is getting at is partly the problem described in ProgrammingOutsideTheCube. The cube's form follows its function because it makes the person visible in the corporate address space. But its form and function are not one because it takes away from corporate dynamics; a person in a cube is neither in a private space where they can achieve the MentalStateCalledFlow, nor in a public space where they can achieve the SocialRelationshipCalledCooperation?, both of which are vital to the corporation's life. The form follows the function, but interferes with it.

A programmatic example of this is the difference between COBOL and PERL. Both are reporting languages at their core; but where COBOL programs look like reports - their form follows their function - PERL programs tend to represent the actual semantics embodied within the reports - they are one with the reports.

Not certain this catches it, PeterMerel.

We've said that FormFollowsFunction and FormAndFunctionAreOne, but we haven't paid much attention to the missing piece: FunctionFollowsForm?. A long while back I used to say form should follow function because FunctionFollowsForm?.

When we say that FormFollowsFunction, we are talking about a design process or a natural process in which molds something as a result of forces. FunctionFollowsForm? is a recognition that form places limitations on the use of a system, and that specifically is what makes design so hard. Our designs can be accommodating or restrictive depending upon what we do. Each decision toward a solution is also a decision against other forms of specialization. Form can be limber or it can be suffocating.

Side note. I actually was an architecture major before starting computer science a long time ago. I moved on because india ink and I did not get along well. I haven't gotten into Alexander yet, but I was always interested in the fact that you there were always things that you could do to make designs better, but they were often things that few architect would have the time to do. It demands a bit of prescience. I see what ExtremeProgramming is supposed to achieve, but it seems so reactive rather than proactive. Imagine ExtremeArchitecture? where you only build the rooms that people need when they need them. Is the amount of refactoring that you have to do less costy than if you planned for them in advance? Perhaps this is okay because software is more malleable than physical material (but less costly to develop?). I do know that it is a great feeling when you get it right and solve problems for people before they themselves recognize that they are problems. Ooops. Enough rambling. -- MichaelFeathers

Imagine a walkthru of your proposed building in a VirtualReality system. "I don't like that wallpaper," you say. Boink, it's different. "The fireplace should be bigger," and it is. "Could we combine the two bathrooms and have a giant hot tub," and you do.

The trouble with planning in advance is that customers don't know what they really want until they see what they've got, and we don't know what they'll really do until we see them do it. ExtremeProgramming accepts (what we hold to be) these truths, and goes with the flow rather than against it. --RonJeffries

VirtualReality isn't good enough (yet?) to do what you suggest. It would be like handing a customer a PaperPrototype and asking "Is it fast enough?"

Some things you don't know until you're actually living with them -- you can't tell from a diagram (or from VirtualReality as we know it) whether the ventilation system will be too loud, or if the cold spot on the outside wall means you can't start your tomatoes in the southern window, or whether the expensive oak mantel on your fireplace will be used as a scratching post by your cat.

On the other hand, ExtremeArchitecture? probably could work. There are ModularHouses?. And didn't BuckminsterFuller design a house with movable walls? And old farmhouses always seem to have all sorts of rambling additions. Most people's interior decorating works in the "extreme" style too -- furniture is purchased only when it's needed, not before. --KatyMulvey

If I may, I'd like to add some thoughts to this. I think what people are missing a little is the physicality of architecture. I consider this its most distinct feature. When Frank and Alexander refer to nature I think they are considering a building as part of a physical context. For them an elegant building was one which worked with the landscape to achieve a function by selectively separating the spaces. I think the analogy may be directly applied to information processing architecture.

Within this definition, an architectural pattern is a system which implements a system quality in a specific situation. This also implies that the implementation of architectural qualities occurs in the detail. Perhaps this explains why non-coding architects suck (oops, blew it there). It also explains why most architectures are very heavyweight. Like skyscrapers they defy nature, and are terribly inefficient. They look only inward to their function, and forget that form is what makes it work well.

Hope this was relevant.

RichardHenderson.

Interestingly Mr. Wright tended to create low ceilings. His form was short which meant low ceilings would function for him, but gives us taller people panick attacks. I think there is a lesson in there somewhere. --AnonymousDonor

I know FrankLloydWright's work mainly from one building, the Baird House in Western Massachusetts. A friend of mine lives in it, so I've spent a fair bit of time there. It's very pretty from the outside, but it is one of the most uncomfortable houses I've ever been in. It's has a number of odd nooks and crannies that are much too small to be useful, and it's quite dark. The floorplan reminds me of the worst examples of University Married Student Housing. The strangest thing about it is the placement of the doorknobs- they're more than a foot above the normal level. My friend loves it because he can tell people that he lives in a FrankLloydWright.

''The trouble with planning in advance is that customers don't know what they really want until they see what they've got, and we don't know what they'll really do until we see them do it. ExtremeProgramming accepts (what we hold to be) these truths, and goes with the flow rather than against it.''

If this were strongly true you couldn't even start your project. It's not weakly true either. Rarely do customers review the choice of nails or the placement of each nail. Rarely does the customer measure every wall, check every level, or worry hundreds of other details about a house. Most of this detail goes completely by the customer and is left to the builder. The number of things a customer is directly concerned with is a small fraction of the possibility space. --AnonymousDonor

See PointAndClickDragAndDrop