Life Update
Since leaving New York, I have continued my journey in computer science. I am currently working through FreeCodeCamp, a non-profit dedicated to teaching the world how to code. Thus far, I am very happy with the tutorials and the program. I believe this will ultimately help me understand how computers work, and how code can help amplify architectural design and improve the built environment. At the very least, it will help diversify my design skillsets beyond the confines of architecture. As the world becomes more and more digitized, it is all the more important to understand the HOW and WHY of computation. I have spent so much time designing and sitting in front of a computer, that for a long time I never questioned the logic behind the software I create, because I was constantly told that it is permanently and continually "out of my scope of work and understanding as an architect, so I should just drop it" (consider it a "local scope" issue, versus a "global" one, in software speak). But I am increasingly critical and doubtful about this division of labor and its efficacy. I am foreseeing a convergence of knowledge and industries, and I want to learn how to translate ideas across fields.
Nested Components in Computer Science
Working through Front-End Development, I am becoming increasingly aware of the importance of systems hierarchy in building any type of large project. In particular, the concept of "nesting" (in JS) or "composing" (in R) is fundamental to computer science. "Nesting" sets up a hierarchy of parents and children classes/objects/components, between which data flows. Hierarchy is also important in the communication between systems, such as stylesheets, scripts, and the DOM. Without the proper systems hierarchy or setup, the program may break or become corrupted. In a more basic way, nesting just helps you stay more organized, just like how Sass (.scss and .sass) allows a nesting of stylesheets. Creating hierarchies, and also editing and breaking down hierarchies, is more or less how anything worthwhile gets built, in both mechanical, and digital spheres.
Design Hierarchy
This discovery made me think about design hierarchies -- and why folks always struggle to understand and communicate them. Human beings are very adept at using critical thinking to create analytical (so-called "left brain") systems, but they seem to be far less able to articulate creative (so-called "right brain") systems. Proportions, scales, ratios, and rhythms underpin a lot of creative industries, such as music, art, dance, and theater. Yet, our culture seems adamant about considering these fields as purely intuitive and subjective pursuits, and lacking clear objectivity. We want to celebrate individual geniuses, or avoid the risk of offending others, because engaging in fair, open, and honest design criticism is too arduous and difficult; it is much easier and faster to proclaim that "all design is good, and everything is subjective", or "You're wrong, I'm right". There are some serious, though hidden, downsides to this. Without proper feedback, people cannot improve their skills; without objective evaluation guidelines, products and projects are inconsistent; and without articulating the effort, reasoning, and mastery behind creative works, it is difficult to quantify financial compensation. Every field deserves a clear set of rules and the ability to describe them accurately and truthfully. Without a proper foundation, you cannot justifiably innovate and "break the rules".
Connections to Architectural Project Delivery
Consider the concept of "nesting" in architecture. Putting together a building requires coordinating thousands of physical components, financial transactions and man hours. To achieve all of this and organize the project clearly, architects create detailed drawing sets and project manuals that illustrate an accurate hierarchy for construction. We start with an overall site plan, then hone in on foundation plans, slab plans, and future egress plans. Further into the drawing set, we arrive at individual floor plans, then elevations and sections, and then finally construction details. The details are set up from 1/4" to 1/8" to 1/16" scales, zoomed in to the required level of detail for construction. We can conceptualize a building as a large program, with construction details as nested objects within larger components, which also live within a larger parent object of the building. Callouts are a series of "hyperlinks" that allow you to move from one component to another, uni-directionally towards smaller and smaller components, until you often arrive at manufacturer's specs.
Design Hierarchy in Architecture
You would imagine that the smallest detail somehow relates back to the larger building at hand -- that, the generative logic used to design the building is also used to create the construction detail. While this is the ideal scenario, in most cases reality requires a lot of compromises. A construction tolerance doesn't fit site conditions. A supplier doesn't have a particular part, and a replacement part requires re-spacing. A project manager or client does not like a certain "look". Then, a series of "one-off" conditions pile up, and a "generative logic" slowly breaks. The design concept does not so easily flow from the macro-level to the micro-level, and the job of the expert project manager or architect is to try to keep the design intent working as long as possible. What you end up with is less than ideal, but that is the price of bringing an idea from a pure, unfettered abstraction to a compromising reality. Sometimes, no matter what you do, you just end up with a salad -- a series of incongruent design elements that don't really work together that well (in computer science, a broken or buggy code).
Moving Forward
How can architects make sure that the design intent remains in the finished product? Besides better communication and coordination, I think it starts at the top, at the initial stages of planning. The difference comes down to how you set up the system in the first place, and how efficient and clear it is. If the project concept is clear and sound, with a clear hierarchy of priorities established, then the troubleshooting issues further down the road can be resolved more easily. Because you can't win every design battle, having the a clear and honest parti up-front is extraordinarily helpful, without needing to introduce weird one-offs and externalities so early on. As systems become more complex over time, with greater and greater chance of corruption and failure, "refactoring" designs and systems over time (to become more simple) is crucial for project success and long-term maintenance. Simplicity is hard to achieve, but project failure is worse.
Since leaving New York, I have continued my journey in computer science. I am currently working through FreeCodeCamp, a non-profit dedicated to teaching the world how to code. Thus far, I am very happy with the tutorials and the program. I believe this will ultimately help me understand how computers work, and how code can help amplify architectural design and improve the built environment. At the very least, it will help diversify my design skillsets beyond the confines of architecture. As the world becomes more and more digitized, it is all the more important to understand the HOW and WHY of computation. I have spent so much time designing and sitting in front of a computer, that for a long time I never questioned the logic behind the software I create, because I was constantly told that it is permanently and continually "out of my scope of work and understanding as an architect, so I should just drop it" (consider it a "local scope" issue, versus a "global" one, in software speak). But I am increasingly critical and doubtful about this division of labor and its efficacy. I am foreseeing a convergence of knowledge and industries, and I want to learn how to translate ideas across fields.
Nested Components in Computer Science
Working through Front-End Development, I am becoming increasingly aware of the importance of systems hierarchy in building any type of large project. In particular, the concept of "nesting" (in JS) or "composing" (in R) is fundamental to computer science. "Nesting" sets up a hierarchy of parents and children classes/objects/components, between which data flows. Hierarchy is also important in the communication between systems, such as stylesheets, scripts, and the DOM. Without the proper systems hierarchy or setup, the program may break or become corrupted. In a more basic way, nesting just helps you stay more organized, just like how Sass (.scss and .sass) allows a nesting of stylesheets. Creating hierarchies, and also editing and breaking down hierarchies, is more or less how anything worthwhile gets built, in both mechanical, and digital spheres.
Design Hierarchy
This discovery made me think about design hierarchies -- and why folks always struggle to understand and communicate them. Human beings are very adept at using critical thinking to create analytical (so-called "left brain") systems, but they seem to be far less able to articulate creative (so-called "right brain") systems. Proportions, scales, ratios, and rhythms underpin a lot of creative industries, such as music, art, dance, and theater. Yet, our culture seems adamant about considering these fields as purely intuitive and subjective pursuits, and lacking clear objectivity. We want to celebrate individual geniuses, or avoid the risk of offending others, because engaging in fair, open, and honest design criticism is too arduous and difficult; it is much easier and faster to proclaim that "all design is good, and everything is subjective", or "You're wrong, I'm right". There are some serious, though hidden, downsides to this. Without proper feedback, people cannot improve their skills; without objective evaluation guidelines, products and projects are inconsistent; and without articulating the effort, reasoning, and mastery behind creative works, it is difficult to quantify financial compensation. Every field deserves a clear set of rules and the ability to describe them accurately and truthfully. Without a proper foundation, you cannot justifiably innovate and "break the rules".
Connections to Architectural Project Delivery
Consider the concept of "nesting" in architecture. Putting together a building requires coordinating thousands of physical components, financial transactions and man hours. To achieve all of this and organize the project clearly, architects create detailed drawing sets and project manuals that illustrate an accurate hierarchy for construction. We start with an overall site plan, then hone in on foundation plans, slab plans, and future egress plans. Further into the drawing set, we arrive at individual floor plans, then elevations and sections, and then finally construction details. The details are set up from 1/4" to 1/8" to 1/16" scales, zoomed in to the required level of detail for construction. We can conceptualize a building as a large program, with construction details as nested objects within larger components, which also live within a larger parent object of the building. Callouts are a series of "hyperlinks" that allow you to move from one component to another, uni-directionally towards smaller and smaller components, until you often arrive at manufacturer's specs.
Design Hierarchy in Architecture
You would imagine that the smallest detail somehow relates back to the larger building at hand -- that, the generative logic used to design the building is also used to create the construction detail. While this is the ideal scenario, in most cases reality requires a lot of compromises. A construction tolerance doesn't fit site conditions. A supplier doesn't have a particular part, and a replacement part requires re-spacing. A project manager or client does not like a certain "look". Then, a series of "one-off" conditions pile up, and a "generative logic" slowly breaks. The design concept does not so easily flow from the macro-level to the micro-level, and the job of the expert project manager or architect is to try to keep the design intent working as long as possible. What you end up with is less than ideal, but that is the price of bringing an idea from a pure, unfettered abstraction to a compromising reality. Sometimes, no matter what you do, you just end up with a salad -- a series of incongruent design elements that don't really work together that well (in computer science, a broken or buggy code).
Moving Forward
How can architects make sure that the design intent remains in the finished product? Besides better communication and coordination, I think it starts at the top, at the initial stages of planning. The difference comes down to how you set up the system in the first place, and how efficient and clear it is. If the project concept is clear and sound, with a clear hierarchy of priorities established, then the troubleshooting issues further down the road can be resolved more easily. Because you can't win every design battle, having the a clear and honest parti up-front is extraordinarily helpful, without needing to introduce weird one-offs and externalities so early on. As systems become more complex over time, with greater and greater chance of corruption and failure, "refactoring" designs and systems over time (to become more simple) is crucial for project success and long-term maintenance. Simplicity is hard to achieve, but project failure is worse.
RSS Feed
