Why We Need More Than Just Scripts

Scripts are great but it's not the solution to everything

I love computational design, but it shouldn't be used all the time. Like most things, there is a time and a place for it. Sometimes we get so caught up in the excitement of automation that we forget to consider the long term impacts of what we create. Tools like Grasshopper and Dynamo are incredibly powerful, giving anyone the ability to create anything without traditional programming knowledge. But because of that, we some times forsake the best practices that software developers have spent decades establishing.

The Blurred Line of Modern Automation

The beautiful thing about computational design is how it blurs the lines between software development and industry expertise. Architects can build parametric models, engineers can automate calculations, and designers can create custom workflows – all without writing a single line of code. Even before Grasshopper or Dynamo, everyone was doing the same thing with Excel. With tools like these, anyone can create a custom workflow in hours instead of days. But there's a tradeoff, we give up robustness and scalability as the result of our increased speed. We start to run into issues like deployment, maintenance, security, and documentation. Anyone who's ever tried to "deploy" an Excel file to an entire company will know how hard this is.

Issues that the software industry has developed robust approaches to. Yet in computational design, we often overlook them in our rush to solve immediate problems. We are often too focused on solving the problem that we don't stop to think about the longevity of our solutions.

What's a Script and What's a Tool?

In our practice, we've started using specific terminology to help people think clearly about their solutions. Not only does it put names to the types of solutions we create but it also helps everyone around us understand what to expect from computational design.

In my experience, computational design solutions fall into two camps, scripts and tools.

Scripts are:

• Quick to create

• Perfect for proof of concepts

• Ideal for one-off tasks

• Usually tied to specific programs

• Often lack error handling and documentation

• Typically used by their creator or only by people familiar with the programs

Tools are:

• Carefully planned

• Built with proper software development practices

• Platform-independent when possible

• Well-documented and maintainable

• Include error handling and user feedback

• Designed for distribution and long-term use

This isn't just semantic difference, it's also about the mindset when we create these solutions. When we call something a script, we acknowledge that it's temporary (however long temporary is). When we call something a tool, we commit to maintaining it properly. By knowing if we are building a script or tool for someone, we can shift our mindset accordingly.

Not Every Script is a Tool

As tempting as it may be, not every script should be made into a tool. Tools come with a level of robustness that is important for wider adoption but it's also more costly to develop and maintain. In fact, this additional cost is what makes scripts so valuable, it's cheaper and easier to create than a tool.

If you do want to turn a script into a tool, here are the questions I ask myself or others when deciding whether to make that investment:

1. Frequency of Use: Is this something that will be used regularly, or is it a one-time solution?

2. Number of Users: Will others need to use this? How many?

3. Critical Nature: How important is this to core workflows?

4. Maintenance Needs: How often will this need to be updated or modified?

5. Complexity: Is the logic complex enough to warrant proper development?

6. Format: Is the fact that it's a script hindering the users?

Making the Transition

If you've decided to turn a script into a tool, here are some practical steps to get started:

1. Document the Current Process: Before changing anything, document how your script is currently being used. What are its inputs? What are people's expectations? This becomes your baseline for improvement.

2. Test with Real Users: Get feedback early and often. A tool is only useful if people can actually use it. See if you can mock up how a user will use the tool and then get feedback on that

3. Build in Flexibility: Tools should be adaptable. While scripts can be modified quickly for specific needs, tools need to handle various scenarios out of the box. Think about what might change in the future.

4. What's the timeline?: Tools take more time and effort to create and maintain. Make sure that there an appropriate budget and time to do so. Creating a tool without the proper budget, can make it a worse solution than the script.

Remember, this transition doesn't happen overnight. Some of our most useful tools started as simple scripts that evolved gradually based on user needs and feedback.

A Mixed Reality

The ideal balance between scripts and tools is that scripts should be used for project specific solutions or even as proof of concepts for future tools. Then once they get enough adoption, we spend the proper time and effort turning them into proper tools for the rest of the company to use.

But the reality is that you're more likely to get company wide scripts that should be tools. And some tools that are used so infrequently, that it should have been left as scripts. At the end of the day, it's about budgets and time.

The key then is to find the right balance for your context. Whenever I can, I try to follow this framework:

• Quick Scripts: For personal use, proof of concepts, or one-off tasks

• Documented Scripts: For team-specific solutions that don't need wide distribution

• Proper Tools: For critical workflows, company-wide solutions, or client-facing deliverables

Final Thoughts

If you're just starting with computational design, don't let this discourage you from scripting. Those quick solutions are valuable learning experiences and can highlight where proper tools might be needed. But as you grow in this field, start thinking about the long-term implications of what you're creating.

If you're ready to take it to the next level or are interested in learning programming, then turning an existing script into a tool is a great place to start. But just remember that the goal isn't to replace all scripts with tools, but to use each appropriately. Scripts are still the perfect way for rapid solutions, while proper tools provide the foundation for reliable, scalable workflows.

The art is in knowing which approach serves your needs best.