dynamo vs plug-ins (part four) link

August 9, 2019

This topic has been tackled in four parts, check out my posts from July 31st and August 2nd for the overview of Dynamo and August 7th for the initial discussion of custom plug-ins.

testing and implementation

If you are developing plug-ins, you are developing software. With that, it is important to implement a development plan.

There are many resources covering agile software development that dive into best practices, but it’s pretty straight forward. In general you will need to:

• Write the spec and determine your minimum viable product (MVP)
• Manage the project (like any project) by setting milestones and sprints
• Determine and implement a testing procedure (code and beta testing)
• Iterate on the process until you meet your goals

You can use all the skills you already use to manage your projects or implement Dynamo scripts to develop plug-ins.

If you are willing to dive in to Dynamo and coding and establish script and plug-in libraries at your firm, it is likely that you are an eager adopter of new technology. You embrace change and new things and are willing to try and fail in order to work towards something bigger. Remember: change is scary for most and adopting new technology can be daunting. This is a challenge that is the same for plug-ins and Dynamo. For many people, if software doesn’t work, they may begin to loose trust in your implementation team and not use new plug-ins you develop in the future. A key way to prevent this is to implement a beta testing system. Identify users that will provide honest feedback for the software you develop and that will keep using your software despite running into bugs. As with scripts in Dynamo, just because a program runs on your machine without problems, doesn’t mean it will run on the machine of your co-worker.

adoption and use

The past few years, my firm has been tackling automation. Originally our journey started with Dynamo. Recently, we have decided to shift our focus, adjust our targets, and refocus our energy to develop custom plug-ins for our firm to use. It is a slow process, so we have not yet rolled out any plug-ins to the entire firm, but we hope to be beta-testing early next year.

I can let you know that based on implementing open source plug-ins created by 3rd parties, we have had more usage out of plug-ins than the Dynamo scripts. It is currently challenging to track statistics because we cannot accurately gather data. When we roll out our custom plug-ins, we plan to incorporate features to provide us with feedback on usage so we can evaluate each plug-in we develop. I’m looking forward to getting back telemetry data to evaluate teams usage of our tools, and I will keep you posted on our findings.

Custom Plug-In Pros:

• No dependency on other users/content creators
• More control over interface
• Access to entire Revit API

Custom Plug-In Cons:

• Requires knowing how to code using C#
• Requires additional software to compile
• Trouble shooting and testing can be a longer process

and the winner is...

When you have a complex problem, there are many solutions. For automation, there will always be the conversation of Dynamo versus custom plug-ins. There is no correct answer, and frequently the answer is both. Teams who want to quickly develop solutions for their project can jump into Dynamo and write a script to make their process more efficient. Those leading the firm’s digital practice can put together plug-ins for the most common tasks that benefit the entire firm. Currently, our firm has implemented goals for Revit plug-ins (custom, open source, and purchased) to assist with our process. Take a look at your process and where you want to see your firm going. There are many pros and cons for both methods of automation, but only your team can determine the best strategy for you.

Check back next week to find out how I learned to code and where you can go to start your journey to developing a workflow that’s right for you!