Why Dynamo is like Ruby on Rails

(to me for one particular use case)

Dynamo is a great visual programming environment for Revit (or Vasari). It’s not just for computational design either. You can do all sorts of cool things with it. It exposes a lot of the API that can be hooked up quite easily with all sorts of automation. I am a complete newb at using this tool, so please don’t take my thoughts as “expert opinions”.

To illustrate the point of my title: I was working on a project recently that needed lots of instance parameter values in a Revit project updated automatically by reading external data. Being lazy, I didn’t want to fire up VisualStudio and hash out a full on add-in to perform this menial task. Being fairly new to the Dynamo world, I thought to myself, “this is probably something dynamo can handle easily and with little effort.” So I dove head first in and built my graph. It wasn’t very complex and took me all of 7 hours to build. I was learning to use the tool as I went.

Capture

It worked perfectly. It did everything I wanted it to and it was almost like magic! I was stoked, to say the least. All my dreams would soon come crashing down whence I learned two simple pieces to the final puzzle.

1. We needed to make this process into a “one-click” operation (ie. not have user open Dynamo, load a definition and run it) and
2. The spreadsheet data that Dynamo was pulling to populate the parameters needed to be 2a.) updated on the fly and 2b.) distributed to many remote users. Along the way, the scope of the project changed a little and needed some more computational features and verification checks that demanded it be forked off to a proper Revit add-in since it required a total of two database Transactions (something Dynamo cannot handle well yet).

So I ended up ditching the dynamo definition,re-writing the functionality (along with added features) in C# and that process took more than 7 hours to complete…It’s awesome, but not that awesome to have spent an exponentially greater amount of time to build.

What I have learned about Dynamo (at least for now) is that you better know what you are going to do with it and know its limitations (like RoR). My experience was that the tool was excellent for a proof of concept and to draft ideas quickly with a minimum viable product (MVP). However, (again, like rails) it starts to snowball problems as soon as you try to do any sort of “enterprise” grade stuff with it or if you need certain API members that it doesn’t expose. It may take longer to build the product in another language, but you will get the level of complexity required. Yes, even with Python scripting…

An example of using the right tool for the right job. Obviously dynamo wasn’t the right tool for my requirement even though the initial results were amazing. This effort has piqued my interest to explore further the potential of something along the lines of building an initial dynamo definition as your MVP, then pushing out to a proper Visual Studio solution as a “hand-off” to a developer team. They can then build a robust add-in without starting from scratch.