The Mind of an Architect
99percentinvisible.org
99percentinvisible.org
Lundy is quite a contrast to Phillip Johnson. Like the other giants of the Sarasota School, Twitchell and Rudolph, Lundy was a veteran [1]. Johnson was an early fan of the Nazi's [2] -- something my mentor, the late David Crane FAIA, never could forgive.
[1]: Lundy's wartime sketchbooks at the Library of Congress: https://www.loc.gov/pictures/search/?q=LOT%2014007&fi=number...
[2]: A recent article: http://www.vanityfair.com/culture/2016/04/philip-johnson-naz...
I work as part of a research lab in a large architecture firm where we are working on ways to communicate the importance of energy efficiency, housing affordability, adequate daylighting, material health etc to the clients, and deliver computational tools to architects, urban designers, interior designers and urban planners so that they can being working with these issues. I have never encountered a situation where someone has opposed or been reluctant to engage these concerns.
This is a very long story, but the short version is that genius is rare, and tradition restrains the mediocre and outright bad, limiting the damage they do and occasionally boosting them up near the genius level. Geniuses who can work without the constraints of tradition, it turns out, can do their thing regardless of the constraints put on them, so it all works out.
Now, this doesn't matter so much in the art world because there we can simply ignore the non-geniuses.
Unfortunately, this is not the case with architecture.
One of the main annoyances for me has been that, although the domain is completely different, in many ways it's just like designing software in that it can be very involved, with many interactions between small details that quickly multiply.
However, as far as I can tell, while software has stolen some "architecture" terminology, architecture has yet to learn some of the recent advances from software, in terms of prototyping, minimal viable products, and avoiding premature optimization.
In architecture, and other fields, you can build your documents incrementally. But it's expensive to actually build something. So it makes sense to "prematurely" optimise the design.
As an example, coming up with a vague sketch, possibly even hand-drawn, or with inaccurate measurements, to present to a client quickly, and get feedback on, before progressing to a more details.
At least with the architects I've worked with, they have a tendency to present plans A, B, and C, which are all incredibly detailed, with exact measurements 3-D renderings, etc, all beautiful to look at. However, it then turns out that I, as a client, really don't like some fundamental things about plan A and B, but can combine aspects of them, and that plan C involved some materials that cost 10x the alternatives, or aren't permitted for use in the building, and are basically a waste of time to discuss.
I'm just suggesting that it's good to get client feedback on things at an earlier stage, before fleshing out the detail on things that turn out to have fundamental problems.
I have found from experience that if I give a binary, they will, ever treat it as a mere sample, no matter what mickle warnings I send with it. They will treat it as the "official" version and ask questions about why various things work as they do, or why certain things are missing.
This can be very distracting if you are not prepared for it. So now I make sure that anything a customer sees is a release in some formal sense, and belongs to a proper release process, which includes QA.
MVPs/sketches/prototypes are valuable in software, in that they 'prove' something, or set a general outline for how the program will grow.
In architecture, vague plans are unhelpful, even misleading. What if you design, say, an indoor plan with inaccurate measurements and later find out that the bed is not going to fit in the bedroom? All your work is for naught, and your changes are going to affect everything else, as your bedroom displaces the kitchen, the moved kitchen shifts the bathroom, etc. In some ways, it's better to start with accurate plans and design while you're 'in deep', than to get a general vague sense. DFS than BFS, to use an analogy.
Or to use another example -- it's very important in software to know what platform your software will run on before you develop it. You wouldn't just make a vague program before knowing whether the software is a native iOS app, a web app, a unix background process, a distributed database, etc, etc, right?
Of course, there are sketchy versions that architects do all the time - program sketches, massing diagrams, et cetera. But anything that isn't completely abstract or pretty accurate will invariably be completely misunderstood by the client.
I've even been burned on a web design project this way - I thought color-coding the wireframes to indicate different functionality would be a helpful idea. Never again - I had to explain over and over that, no, their website would not be a sea of nested red, blue, and green lines.
Oh they would love to. The client has to pay for that, though.
Prototyping is usually done at an 'Architectural' scale like urban design, international airports, 'Gigafactory', or very large apartment buildings in cities. It's just not affordable or practical (time or money) for the single-family home.
Examples of client costs which must be passed on to the consumer may include 3d rendering/animations at the very simplest. U.L. Certification for any un-listed building product OR assembly (e.g. how a wall is put together with your new material) is somewhat common - like living in a reclaimed steel shipping container building in the past or using a airplane fuselage/boat hull now. Fire ratings are also often required and that's almost always a destructive test - the cost is double or triple for that new tent roof design assuming it passes the first time. Be prepared for the insanity of earthquake tests if you design a new transparent block you want to use in your wall - even if it's not load bearing. A simple custom rubber gasket will require water/air pressure tests in many cases and that's pretty common for glazing systems.
Every building design is an MVP - it must comply with with the 'Building Codes' (IBC/NFPA/AISC/etc.) which by definition is a set of rules for building a safe MVP. Beyond the MVP you hire a specialist like interior designer/landscape arch/audio specialist and even then there are laws which must be followed (smoke/flame spread, permeable land usage, etc). No extra information is ever added to the construction docs (blueprints) because they're a contract too. And every element either graphic or textual will incur a liability and/or expense within the set of drawings and written specifications.
AEC's work out designs in their heads and translate them to paper for legal approval - that's how they avoid premature optimization. That applies to the schedule too.
When you look at a blueprint and you see 'the cloud' around part of the drawing it's a revision - something has changed - and so the graphic notation for iterative design is built into the conventions for conveying important information.
Take another look at architecture beyond Alexanders 'Pattern Language' books[0] and Frank Ching's awesome sketches[1] used as inspiration for the GoF books[2]. You'll find that there's a lot of applicable ideas for software starting before Imhotep and continuing through today. Philosophically speaking, both disciplines are reflections of the current society at the time of their construction.
[0] https://www.patternlanguage.com [1] http://www.frankching.com/ [2] https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...