Writing a Script Isn't the Same as Building a System

It takes more effort to scale something that most people think

Part of what I love about computational design is how you can automate manual work.

Yes, we all know that it saves time and effort but more than that, you can scale your solution up.

Take modelling for example, it may take you 15 minutes to model a roof in Revit. But a script that took you one hour to write. Can be given to 10 other modellers on your team and you would have ten roofs in the same time. Ten roofs that are of consistent quality.

You’ve effectively scaled your manual effort by 10x because you made a computational solution

It’s like when live concerts were the only way to hear music a few decades ago. Now, we can stream any music we want. The cost of reproducing a solution whittled down to near zero.

Thank you internet and digitalization.

But even though it became easier to distribute music, the process of making music didn’t become follow the same trend. In fact, it became even more complicated. Instead of just showing up and playing the music, musicians now have to worry about how to record their sound, what kind of files to create, what kind of platforms they want to upload to, and the list goes on and on.

It’s the same thing with computational scripts. Before, the way someone solved a problem lived in their head. Now, I can bake that process into a script and hand it over to someone or everyone on a team to reuse the same consistent process.

At least, that is the promise of computational design itself. But we know that isn’t the entire story.

“Oh, we solve this kind of problem all the time, putting in the effort for a script now will solve all the same problems in the future”. Said an overzealous and younger version of myself.

I remember pouring days into a script on the faith that it will be reused several times, even when the manual way would have halved the time. After all, the promise of automation is to put in the effort now, so that you have little to no effort to reuse it later.

Somewhere along the line, we started prioritizing the reusability of computational design instead of focusing on what it means to make a good solution. That if a task wasn’t repeatable, there was no point in doing things computationally. That for some reason, the script had to be used more than once to make its effort worth it.

But to reuse scripts is whole other challenge.

When we build scripts to solve a specific problem, it’s usually within the timeframe and context of a project, which has a lot of assumptions that we don’t see. Things like the way the files are structured or even something as trivial as how they are named.

These seemingly “small” assumptions can break computational solutions. You can’t reused a computational solution unless the exact same assumptions and conditions are met again. And no two projects are alike.

Sure, you can put tweaks in to accommodate for it. But what if you now have two projects of opposing features? One project need their file named with the date in the front and the other needs the date in the back. Will you make two scripts or will you tweak the script to accommodate both ?

Oh, it gets worse. Have you ever tried to give someone a computational script for them to run?

Before computational design, you could get away with just handing someone an Excel file or a word document with your equations on it. But now, with Grasshopper or any computational solution, you have a whole heap of things to worry about. Dependencies, licensing, permissions, etc.

I think back to the music example, where all you had to do before was made sure your Excel file worked. Now, you have a long long list of other things you have to worry about to distribute your solution.

Okay, I know as I write this, it seems like I am against computational design. Well, I am not. It’s my career after all. But over the years of doing this, I’ve come to understand that solving a project problem is very different from solving a pattern problem. And for scripts to be reusable, it must solve patterns, not specific problems.

So contrary to common belief, it means that most computational scripts are not reusable outside of the project.

It’s not that you shouldn’t build scripts. That would be hypocritical. Quick solutions are half the value of computational design. The ability to spin something up in hours and save someone days of manual work is genuinely powerful.

It’s that, not all computational solutions are reusable or do they need to be.

When something works, there’s a temptation to think, oh, I have the ‘exact’ same problem here, let me just reused the script. But a script that solves your problem, on this project, with this data, is not the same as a script that solves the pattern.

And thinking that all scripts are reusable is a false promise that will blow out your budgets and timelines.

Turning any project solution into a global one requires a different kind of thinking. You have to abstract away the specifics. Handle inputs you didn’t expect. Document what you assumed. Test against cases that didn’t exist when you built it. It’s a reason why software development is a whole industry in itself.

These days, I sound like a skeptic to everyone.

Because everyone is excited about the promise of computational design and I have to be the one that ruins their party. But I have to be truthful about these things because to dangle the promise of re-usability even when it’s not entirely true is cruel.

A script that works is a win. But it’s a local win. It solved a problem in a specific situation. We can’t expect to reuse that everywhere else. If we want it to work again, we have to put in the effort to ensure it can be scaled. It never is build it once and reuse forever.

That’s the difference between solving a problem and building something that lasts. It’s the main reason I always tell people that We Write Code, But We’re Not Software Developers

Want to learn where to apply computational design?
Subscribe to CodedShapes and I’ll send you my free guide on how to actually do that