“Learn visual programming” was the hard-fought closing remark to the computational panel, which Ben Howes and I had the privilege to be a part of (video here). Hard-fought in the sense that Ben stole these words right out from under our new and good friend Frank Fralick (developing Dynamo for Autodesk’s Inventor), who appropriately had these words in his last set of slides—Ben and I of course did not. While Frank presented his work on turning digital designs into fabricated realities, Ben and I presented Remote Solving: a platform for allowing near instantaneous engineering feedback to our clients using the cloud. Also taking part in our panel was the team of Harry Mattison and Robert Manna from Boost Your BIM and Stantec, respectively, who shared their work on using a shortest walk algorithm to better design the walking distances between rooms in hospital planning. I couldn’t think of a more appropriate example of how to use this algorithm myself!

But let’s get back to learning visual programming. First, to be clear, when we say visual programming, we are referring to computational programming that relies not on the writing of text-based code, but on the connection of graphical nodes or components to create a similar logic system. Think: Grasshopper for Rhino, Dynamo for Revit (and soon other Autodesk products like Inventor) and Generative Components for Bentley.


Left: Example Dynamo script. Right: Example Grasshopper script.

This is important because learning these tools instills a procedural way of approaching design problems. Working with these software platforms forces you to consider design relationships at multiple scales, from the finest of details, all the way to the macro relationships and drivers that govern the overarching logic of the project. Aside from creating far more precise models that are able to iterate through many design options, it is largely a different way of approaching problem solving than what many of us are used to. In design education there is an emphasis on ‘the one,’ or the belief that a singular idea can be refined and re-refined until it is truly perfect and fully resolved. In engineering education it is much different, but ultimately it is too often boiled down to right or wrong and black or white. What visual programming allows is for the exploration of the ‘gray’ design space in between, which is all of the possibilities in and around that one great idea. In these adjacent areas of the design space, options can be exposed that may lead to solutions that are better than the original intent.

Continue reading…