*Edit, sorry i'll address you by the account you're posting on* - Liberty Bell, great questions. Two main points to this (though I could go on forever on this subject, it was a key part to my thesis work). If I remember correctly you dont really have any experience in scripting, correct?

1) Ive said this many times to friends and coworkers - everyone thinks they know how to script in Grasshopper (or 'x' software of choice). My general response is to ask them how they would do a round-trip complex data-tree reorganization. I dont actually need them to tell me what to do specifically, I just need them to start describing the process to me; this usually outs the posers in about 30 seconds. The reason being that, fundamentally, it's all just patterns of 1's and 0's, isolating the sequences you want, and aligning them to the ends you're trying to achieve. There are infinite ways to do this, which may give the same results, different results, or most crucially, results that appear to be the same but really are not. What I mean is - the process/sequence that the scripter defines actually matters quite a bit, if you're trying to achieve a certain accuracy or tolerance. A > B > C > D is not the same as A < C > B > D, but the subtleties can be so small that a dilettante won't see it.

2) Computational design and digital fabrication are related, but not interchangeable (same goes for 'parametric', 'scripting', 'geometric', etc. All these words mean related, but specific, variations of similar things). People love to work with 3D surfaces because they are fun to manipulate and easy to make cool-looking shit. But reality is a bitch, and flat surfaces don't exist in the real world. Everything has thickness, which means tolerance testing is crucial to the success of any project - which as architects we obviously understand very intimately in all aspects of our built work, but are all too quick to glance over in model space - because its hard. Not addressing this is essentially just cheating.

So my diagnosis is a fairly common one. There were likely two failures in the process that lead to the cut-files not being as expected (for this specific example; i'll get to a broader statement). First, in producing the scripted work, there was likely some piecing-together of other scripts (usually found on the internet) into the working file, without proper vetting. This means that an amount of tolerance was sacrificed because someone didnt understand 100% of what was going on, because they didnt do the full work themselves. Second, there was an expectation that because it was 'computational' it was totally correct, and look-i-can-see-it-in-my-model-so-it-must-be-true-right? But test files and mock-ups are so crucial in translating between the two. Designing with script doesnt free someone of the iterative process, it only reinforces the need for it.

TL;DR - people need to understand that the subject of computational design is actually very robust and complex. It is not pretty pictures and sexy renderings. It is methodical, it is precise, it requires proper study of the subject and a conceptual understanding of the way in which the system works. It is data, it requires correct application.

Bench, thank you for this! And you're correct, I don't know scripting. I'm curious about it because I'm excited for how it *can* impact architecture. I'm excited for the self-assembling builder bots! 

Like you say it's not about pretty pictures and sexy renderings, but those things are what sell the idea. I just want honesty in how it's used. 

Another project I know of *did* use the computation correctly and had tolerances across a 40' surface down to 1/8" in all three directions which is spectacular and cool but! in a typical weather cycle from spring to winter the building on which this was installed moved more than that. So now all the pieces are wonky.

There's some friction between material and modelling accuracies, obviously. I'm fascinated by it.

Donna, I looked back at your post a bit more.

" Isn’t the entire POINT of computational design that things will perfectly work? "

- Not necessarily, but I can understand the sentiment. Simply put, its a robust method for developing systems of rationalization for things that are inherently irrational. Previously, there hasn't been a better way to address this. The onset of computational and rules-based systems, as well as the capacity for the broader workforce to now understand and achieve this through visual scripting like Grasshopper (rather than typed code) just makes the difference seem to be massive; we see the delta in the shift rather than the substance of the new ends. Computational work flows can and still do fail, or at least create new problems all the time.

" Is this a terrible case of an architecture professor not knowing anything about the actual practice of what they’re teaching? "

YES. Or at least not knowing it as well as they think they do. It comes back to that longtime adage of types of knowing: 1) Knowing what you know, 2) Knowing what you dont know, 3) Not knowing what you dont know. Seems like a classic case of the third in this sense; its not to do with computational design specifically, but a fundamental miss on the part of the professor to exercise a self-critical analysis of their own understanding on the subject. And it refers back to my comment about people 'actually' understanding what the 1's and 0's mean, or focusing on the image instead of the code.

" Is it a complete failure of Modernism? "

This doesnt seem very relevant, to be honest. I actually think theres an interesting debate to be had that the current digital design/practice world is an entirely different/evolved way of thinking about design, beyond Modernism and Post-Modernism; in a similar manner that contemporary art has completely left much of main modernist art theories and texts behind. See the OMA article discussion going on about the towers in Brooklyn yard and the evolving typology of towers.

" Is it yet another example that architecture is a material process that relies entirely on the skill of the hands that are building it? "

And this just comes back to my original point, that these digital workflows still need to address the real world, ugly/tough as it may be. Similar to a theory lecture that doesnt refer to anything substantive in practice.

I've been quite lucky to have worked on a number of projects where we could not have achieved the goals without these scripting tools. It goes through the same process with manufacturers as any other component (albeit a much more complex deliverable). So perhaps this is more of a failure in academic discourse not totally being able to give good instruction due to a lack of professional exposure. Profs still need professional experience to prepare students for the working world, period.

Everyone's a grasshopper pro, until they get tested.  I was the digifab person for my grad school and the amount of puffery that I overhead was crazy, but that's beside the point and honestly, I know that there's a lot that I have to learn myself.  

With "computational" design, there are bugs that come up but for the most part it's a one shot thing.  Software like Word or Chrome are constantly being written and improved but most of the projects that I've "computationalized" end with a static object and the script gets moved to an archive folder.  Sometimes, I'll go and pillage a part of it but any of the "issues" that were found creating the thing never get resolved (a tolerance that I didn't think about or a material thickness that fluctuated more than anticipated) because no one budgets for iterations/improvements and I've moved on to the next project (problem).  I have a bunch of projects that took a long while/intensive head scratching to create the workflow that I could now tweak some parameters and spit out new versions of the installation in a few days when the initial took months.    

I once interviewed with a prominent "digifab"-intensive branded firm that had a project similar to something in my portfolio/is well published and won digifab awards, I found out that a large portion was actually manually fixed because of issues that arose.  I was proud that my small group of peers was able to do something better in a much much shorter timeframe!  

TL:DR, Just because holes don't line up, I wouldn't discount the computationalism of the project.  These are very complex projects with a lot of thinking that goes into them.  A large portion of the project is learning from ones mistakes for the next time. Most hype computational fabrication as an easy CSI enhance image with just some keyboard mashing, send it to the machine and out pops a cool thing but in reality, those Kuka robots have to be checked to make sure that the path doesn't cut back on itself, a CNC doesn't cut too much of the material keeping it on the spoilboard before cutting the rest of the thing out, 3D printed object has enough supports, etc

sure. 

Isn’t the entire POINT of computational design that things will perfectly work?

no. this is sort of like saying “isn’t the entire point of a pencil that it can be used for math homework?” computational/associative/algorithmic/parametric (related but not interchangeable descriptors, as Bench eloquently stated) design processes are used for many more purposes than just complex fabrication and intricate assembly. optimization, form-finding, rapid iteration and prototyping, quantitative analysis (of potentially infinite input streams), machine learning and ai integration into design workflows, material science testing, and advanced cost estimations are just a few of the applications of computational design techniques. 

Is this a terrible case of an architecture professor not knowing anything about the actual practice of what they’re teaching? 

no. professors who teach “computational design” have some knowledge, and probably have advanced understanding, of the theory behind what they teach and/or practice. they may not have advanced skills with every piece of design software, and they may rely too heavily on students to execute their intentions, but “not knowing anything” is not how professors in relatively niche areas of study get hired to teach in those disciplines. 

Is it a complete failure of Modernism? 

no. this question suggests a larger and more troubling misunderstanding of what Modernism is, which is a conversation for another thread. 

Is it yet another example that architecture is a material process that relies entirely on the skill of the hands that are building it?

no. materials are obviously a critical component in any architectural endeavor, but any intelligent application of computational tools includes detailed material property analysis in its solutions. if those material properties are ignored by the project’s author, the result will likely fail, like this professor’s work. but this failure is in no way representative of “computational design” as a whole, which like any other tool, must be used properly and skillfully to yield successful results 

Yes to all, I think.

no. again, none of this is meant as a defense of this professor, whose bullshit attitude is an embarrassment to those of us who take this area of research and practice seriously. the larger concern (to me at least) is the perpetuation of these superficial and wholly ignorant ideas of computation in architectural discourse, especially by those who are completely (and to donna’s credit, admittedly so) uninformed on the subject. 

"a robust method for developing systems of rationalization for things that are inherently irrational"

Now all we have to do is decide if actual building construction is rational or irrational.

This is such a great conversation, I really am learning from it!  Thank you all for being generous!

I admit I know nothing of scripting, but I'm in the process of using and learning Revit. And for me, because building physical objects is the part of architecture that I'm most enamored with, the idea of building the whole house (or whatever) in the computer, like actually model-constructing every stud and nail and shingle and flashing, is nirvana. But I don't know how to actually do that, yet, and it's likely not a very efficient use of the computing energy.

My comment about the failure of Modernism relates to the idea of form following function. Which of course is a pithy summation of Modernism, and is a much bigger topic. But what it leads to for me is loving objects that use the absolutely minimal efficiently required amount of material. But when the holes then don't line up - argh!!

Anyway, thank you. All of this helps and is fun to discuss.

Actually it was supposed to be 'function follows form' but Louis Sullivan got tanked the night before...

You can call yourself a computational whatever but it doesn't make you a good designer or builder.

I worked on a project with someone who is now absolutely the foremost computational designer building actual projects (well two, since Andrew Kudless is the other). This was their first permanent outdoor thing. I worked for the fabricator. We had to do a lot of education about material thickness, fastening, the thickness of paint, and other such minutiae. The script is only as good as the input, and it sounds like the person in question is an idiot, so go figure....

We also suggested a computational solution (yes, fabricators should be able to code) to this person to solve the doubly curved surfaces they had everywhere on their piece - they hadn't accounted for the difference between doing one of their pieces in 24 ga aluminum and 1/4" plate. To my knowledge this little routine us still used by this firm...

I guess bottom line someone always knows more, so be willing to learn. Oh, and go build some stuff. It's the best.

I'm struck by the number of people, OP included, who jump to the conclusion that the designer is an "idiot" "failure" "terrible" "incompetent".  It is really interesting how we hold ourselves to this zero sum game. 

The same mentality is pervasive throughout the industry. We demand perfection that is in reality not attainable. It leads to a lot of self doubt, undervaluing our services and giving away free work. There is always something that you didn't think about, some issue that will arise.  Either you except that and constructively deal with problems or you carry a lot of stress, work extra hours and give work away for free. 

The promise is never perfection. It is Design, it is Intent, it is a Contract that is to be negotiated in the real world.  

Computational design is not something new.  Everyone has been using it to design. the level of complexity of computation has increased. That doesn't necessarily mean the number of parameters has to increase. The human brain, and realities of site and material are probably best left as simply as possible. In this case said fancy design would have been well served by understanding this and perhaps leaving out that final connection detail to be drilled countersunk and field fixed, or as other have pointed out provided some greater tolerance, slots or connections that accommodate variability in site and material. Something that a mock up might have indicated. 

let's stop holding architecture to perfection. None of us are perfect. and no script will be either.

Dated to 2009-2011, but my 2 cents:

Most of the computational design in my graduate studies involved computational form making and manual cut-file creation which usually started by using a splice/split command of some sort and creating cut files, manipulated in the original program off to the side, or CAD, or sometimes even illustrator.  Some people were very accurate digitally.  Some fudged.  Many had to figure out adjustments, including making new cut files at times, when their fabrications didn't fit.  

If it was a team project or a 3rd party was being used, the cut files almost always didn't work, and in-field adjustments had to be made.  

As someone raised in the trades who was a 1st generation college graduate, I considered the student and/or professor/education process a success if by thesis year, most people had figured out their own set of tweaks (eg: angles with slip joints or something) BEFORE fabrication such that on-site install day went rather smoothly.  

Regarding grasshopper, I wouldn't even know where to begin now, but at the time, I was the go-to for figuring out how to "script" something.  My personal goal was to never grab a bunch of buttons and copy paste them, but honestly I failed at that quite a bit.  Having quite a few friends in CS at the time, I understood that I was barely scratching the surface in actually coding, even with my copious VBscript buttons.  Everyone had their own sets of scripts they would mix and mash together on projects, but no one at the time seemed to have figured out a way to create a grasshopper/VBscript library of their own and actually program, calling out different "functions" from the library as necessary.  The way the professors always talked about a pedagogy, it seemed like this would be the goal.  Imagine a "Zaha" library that you loaded in and could call from that allowed you to do tons of tricks that eventually implemented Zaha work, except replace "Zaha" with your name here and call that your thesis.

LB, Speaking more broadly to whether this is a failure of a professor, I would say no: this is a successful test of a hypothesis with a negative conclusion. Part of the role - and usually a main condition on their tenure - for professors in a research university is to conduct research. i am making the assumption that a 'national architecture school' with this position is part of such a university.

in this case, the hypothesis was the professor's method of developing a fabrication model. the failure shows where that method needs further adjustment.

without specific details it's hard to evaluate whether that outcome was truly predictable. the fact that the fabricator raised no objections suggests it was at least a subtle failure, or a fabricator inexperienced with this workflow. as others point out in real world practice the designers and fabricators would test their digital model and fabrication techniques to find these faults before proceeding to full fabrication.

of course the professor ought to publish this research even if only informally to make it useful. hopefully the experience will make them a better teacher at least.

Schools need to teach analog fabrication before digital. For that matter, professors should learn the former before instructing students in the latter.

I just used Dynamo for the first time today.  Pat on the shoulder for me.

Too bad Patrik is busy suing the Hadid estate. I'm sure he would have some valuable insight on this.

professor must be tenured