dynamo vs plug-ins (part three) link

August 7, 2019

This topic will be tackled in four parts, check out my posts from July 31st and August 2nd for the overview of Dynamo, and come back Friday, August 9th for the wrap up of custom plug-ins.

As we have covered, Dynamo for individuals is fantastic. Dynamo at a firm brings some challenges, but if you have a system in place, you can implement it successfully. In my opinion, Dynamo is best deployed when the firm is small enough that you don’t need full-time resources dedicated to package and script management or when it is large enough to have full-time resources dedicated to package and script management. So what if your firm is in the middle? There is an alternative, but it involves the c-word: coding.

custom plug-ins overview

I always get excited when I find out “there’s an algorithm for that”. You can create custom plug-ins that do exactly what you want to do and that jive with your company standards. Coding is a longer process than scripting in Dynamo, and you need to learn how to code, but it’s 2019, coding is a life skill. You will use these skills to write VBA scripts for Microsoft Office or to use Powershell to automate tasks. You will quickly realize that there are simple things your computer can do for you every day. Once you start coding, you’ll want to apply it to everything.

the learning curve

The barrier for entry to developing custom plug-ins is higher than for using Dynamo. To create custom plug-ins, you need to learn how to code. Thankfully, we are in the 21st century and countless resources allow you to learn on a flexible schedule. You don’t need to study computer science to become a programmer, and you don’t need to be a software engineer to write successful programs. It doesn’t mean it’s easy or that you can pick it up in a weekend. However, if you dedicate time to learning how to code, you can be successful.

fewer scripts, fewer functions

Once you get into it, you will quickly see the benefits of coding. To put it simply, the functionality provided by large Dynamo script libraries can be provided with fewer plug-ins. For example, one of the complicated items of Dynamo is that it is more challenging to set up a run order. You have to use nodes from packages like Clockwork, but even then it gets complicated quickly when you are trying to run five related functions in a specific order. At this point, I just separate the scripts and run them individually. This leads to five scripts in the library instead of one. When coding a plug-in, it is super easy to call functions in a specific order, trigger events using if statements, and provide all functionality related to a certain item in one single plug-in.

The second part of this is that because scripting in Dynamo is intended to allow designers access to programming tools, the nodes are simplified. This equates to you having to string together many different nodes to receive an outcome since these nodes need to work in many different ways. When it comes down to it, a Dynamo graph with 100+ nodes can most likely be written in a couple of dozen lines of code. If you’re willing to commit the extra time to develop plug-ins, you can accomplish more functionality with each plug-in and there are ways to reduce maintenance tasks versus keeping a Dynamo script library.

See you Friday, August 9, to read about strategies for testing and implementation and what our plans are for custom plug-ins.