5 Computational Design Myths I Hear All The Time

Living my dream as a myth buster

Ever heard of the show Myth Busters ? It was a TV series that came out in 2003 about a group of people set out to use the scientific method to prove if a myth was real. I loved the show. Aside from the explosions and robotics, it really made me understand the level of effort it takes to bust a myth. They built most things from scratch and laid out any assumptions they made, then go on to prove the myth.

So today, I am going to live my dream as a myth buster. Well, no explosions or the actual scientific method but I'm going to bust some myths around computational design. These are myths you may have heard from others or social media. And I'm here to give my two cents.

Myth 1: Computational design is just Grasshopper

I blame social media and partly myself for this. Grasshopper is a very visual tool, so it's very easy to only make content about Grasshopper. Do any simple thing and you always get some 3D visual that you can plaster all over Instagram and LinkedIn. Only see Grasshopper on LinkedIn ? Well, Grasshopper must equal to computational design then.

While these isn't a universally agreed upon definition for computational design, I think it's more of a mindset than it is about the tools. It's about using computers to better solve problems. That means we use any program out there to solve a problem.

That means using tools like Excel or PowerBI or even PowerPoint to help others solve their problems. Let's take a look at some of these tools in detail and how they are used in computational design.

Spreadsheets. Yes, you read that right. We still work with "Old school" tools like Excel because it's still very powerful. Everyone still uses Excel, so it makes sense to build workflows around these programs. Far be it for us to tell others to change their approach just because we want to use Grasshopper. So, we supply them with macros and other scripts instead to help them.

Text programming. Languages like C#, Python or even web development are for more scalable solutions. We aren't as good as pure developers, but we know our way around these languages. For example, Revit plugins are made in C#. You certainly don't need to know how to code to be a computational designer, but it's another tool in the arsenal that we tend to use. It's also a skill that computational designers tend to have.

Last but not least. Visual programming tools. Those are your Grasshoppers and Dynamos. There are debates online about which one is the best, but really it comes down to what's available and what's best for the project. Like you can't use Grasshopper with Civil3D, so it has to be Dynamo. And if you need to work heavily with geometry, Grasshopper is a better choice than Dynamo.

And that is just a subset of tools that we can use. There are rendering programs like KeyShot or VRay that I didn't mention. Ultimately, computational design is made from a series of tools, not just Grasshopper. In fact, it always depends on the project and it's almost never only Grasshopper.

Myth 2 : Computational design is not for everyone

Computational design may not be the right solution for every project, but that doesn't mean it's not for everyone. It all comes down to experience and what you have been exposed to. An engineer who learnt Grasshopper will only show Grasshopper solutions for engineers. A drafter who picked up Dynamo will only show Dynamo solutions for drafters. So, it might just be that you don't know how computational design applies to you.

And that's a big problem. It makes people feel like computational design isn't for them. You're an engineer but if you only see architects using Grasshopper, you might think Grasshopper must just be an architectural tool.

But honestly, Computational design is a lot like regular software, you can make just about anything with it. It's almost like learning how to write, you may not be a writer, but the skills for it are universal.

That means if you're an engineer but only see computational design used by architects, it's actually a problem of exposure not computational design itself. A good way to see how computational design applies to you would be to expand your horizon. Maybe find other engineers who have used computational design and talk to them. Or start following other more engineering computational designers on social media.

That said, I think we as computational designers need to get better at communicating too. It's actually why I started this Substack, to show how computational design can be applied to almost anything.

Myth 3 : Computational design is only for the complex

Here's another fault of social media and the internet. There is a lot of complex and flashy stuff out there. It makes it feel like computational design should only be used for these complex projects that seemingly have infinite budgets. NEOM, I am looking at you.

Well, like most social media, that couldn't be further from the truth. We tend to just post the things that look good but most projects that I am involved with are actually because of three things :

• People need to do something that is impossible or very hard to do manually

• People need to put out a fire because something went wrong and it's time critical.

• People need a way to do something mundane more efficiently

The second and third point make up 80% of my work. Computational design is most often used as a way to drive costs down. That means staying within budget, some times even out performing it. It also means you end up just making tools to help improve people's day to day. Like this Excel spreadsheet that I made to manage construction staging in an analysis model.

Don't get wrong though. Complex stuff does exist but they are rare and few in-between. But all we see on social media are complex and flashy stuff. It makes people (well, me) feel bad about their (again, me) own work.

So, computational design is not just used on complex stuff. It's mostly used to make the day to day tasks more efficient that has the most value. And that brings me to my next point.

Myth 4 : Computational design is just a different kind of automation

This is a huge misconception. Sure, automation is part of computational design but it's not the sole focus.

To me, it's about finding new ways of using our computers. Tools like Grasshopper and Dynamo actually give you new ways of working with geometry. Instead of modelling things manually, you can actually tell the computer how you want it to be modelled. It makes the geometry parametric and self-documenting.

And if you don't work with geometry, there are also tools that help you manage data. You can build macros or small scripts in Excel or PowerBI to help to handle BIM or even finance data.

My point is that computational design is a lot more than just automating stuff. It's about learning how to better leverage computers to solve problems. Yes, that includes automation but there are a lot of other things too.

Myth 5: Computational design replaces human judgment

Because of the flexibility of tools like Grasshopper and Dynamo, there is a tendency to just trust that it's doing the right thing. When in reality, it's just another tool. It's a tool that can be used wrongly or correctly depending on your context. Like a knife, you can stab someone or make a great dinner. A more modern example, assuming we aren't all serial killer chefs, is AI. AI is great but you always have to check it's work because it maybe wrong. The same goes for computational design.

Some times computational design can make problems worse. It's easy to fix one wrong element, but imagine 1000 wrongly placed elements because of an error in a script. I have been there, it's not fun.

Any tool that I've built has always been about helping others. It does not take the control away from them. Even if a tool could generate thousands of options, you still need experience and skill to pick out the right one.

It's just another tool in your arsenal, it doesn't take any human instinct out of the process. In fact, it makes it more important.

Final Thoughts

You know why I liked MythBusters so much? Aside, from the explosions and cool stuff. They questioned the way things were done. They always took a step back and asked if things were true.

Computational design at its best encourages us to question our default ways of working. Computers are really fast now, we also have AI, so why are we spending countless hours entering data ?

I know we can't make everything 100% efficient but we can certainly try and get pretty close too.