Laat me ten eerste zeggen dat ik een absolute fan van Autodesk Revit ben. Mijn roots liggen bij de bouwkundige aannemers en de meerwaarde van Autodesk Revit voor onder andere deze branche is enorm groot. Als fan van Autodesk Revit ben ik van mening dat Dynamo een meerwaarde is. Je krijgt met Dynamo veel krachtige hulpmiddelen om snel ‘iets’ te generen in je model. Dankzij de community rondom Dynamo zijn er veel bedrijven die inspelen op het maken van Dynamo-bouwstenen, waardoor het aantal hulpmiddelen alleen maar toeneemt.
Als productmanager kijk ik echter anders naar Dynamo. Het is mijn taak om naar de ‘bigger picture’ van een software-oplossing te kijken. Ik kijk niet alleen of een oplossing snel het gewenste resultaat oplevert. Ik moet ook kijken of een oplossing voor ieder type gebruiker geschikt is. Wat zijn de voordelen van een oplossing, maar ook wat zijn de nadelen? Is het gebruiksvriendelijk? En vooral: wat zijn de risico’s? Als iets werkt voor de ene persoon, werkt dit dan ook voor de andere persoon? Hoe gaan we om met onderhoud en hoe kunnen we gebruikers ondersteunen in geval van calamiteiten? Kortom: allemaal items waar een productmanager zich mee bezighoudt voordat hij opdracht verstrekt om een nieuwe C#-oplossing te bouwen.
Ondanks dat je met Dynamo mooie oplossingen kan bouwen, blijven het allemaal pragmatische oplossingen. De input van de oplossing is zeer afhankelijk van de persoon die de routine heeft gebouwd. De kennis en handigheid van deze persoon is daarbij een zeer belangrijke factor. Niet alleen in het gebouwde resultaat, maar ook in het gebruik ervan. Juist deze kennis en handigheid verschilt van persoon tot persoon. Dit betekent dat wat voor de ene persoon een handige oplossing is, dit juist voor de andere persoon kan leiden tot problemen.
Je ziet dat bedrijven Dynamo veelal inzetten wanneer ze snel informatie uit een model moeten halen. Of wanneer ze een hele bak objecten, voorzien van vele parameters, moeten maken. Voor juist dit soort laagdrempelige toepassingen juich ik Dynamo toe.
Als bedrijven Dynamo echter gebruiken om data of geometrie aan te passen in actieve BIM-projecten, dan word ik zeer sceptisch. Je kunt namelijk met Dynamo snel hele modellen vernielen, met alle gevolgen van dien.
Het allergrootste risico loop je als je een project-specifieke routine gaat gebruiken voor een ander project. Je moet dan goed op de hoogte zijn van wat de routine exact doet, hoe iedereen de input moet aanleveren en welke output je kunt verwachten. Zolang jij de bouwer bent van de routine zal dit niet snel leiden tot een probleem. Als anderen echter dezelfde routine gaan gebruiken kan een verkeerde inputwaarde een behoorlijk destructief resultaat hebben met alle gevolgen van dien.
Als productmanager ben ik van mening dat een Dynamo-script geen concurrent is van een C#-oplossing. Ten eerste zijn er een aantal limieten. Daar kom ik later op terug. Ik kijk vooral naar het proces hoe een C#-oplossing tot stand komt in vergelijking met een Dynamo-oplossing en naar de levensbestendigheid van de oplossing. Uitgaande van een softwareontwikkelaar als Cadac is er bij een C#-oplossing een professioneel team beschikbaar dat aan de oplossing werkt en dat de oplossing onderhoudt. Dit team bestaat uit professionals zoals een ontwerper die zich bezighoudt met de ontwikkeling van user interfaces die voor iedereen bruikbaar zijn. Denk aan een software-architect die onder meer de stabiliteit en de performance van de oplossing bewaakt. Denk aan ontwikkelaars die op zeer hoog niveau de code beheersen. Denk aan softwaretesters die op basis van zoveel mogelijk scenario’s bewaken of de oplossing het gewenste resultaat geeft, rekening houdend met de vele variabelen. En laten we vooral niet vergeten de supportafdeling, die direct klaar staat als er vragen of storingen zijn. Een C#-oplossing, gebouwd door een professioneel team, is daardoor eenvoudiger bruikbaar, is stabiel en heeft altijd een betere en duurzamere kwaliteit dan een Dynamo-script.
Een Dynamo-script wordt door één individu geschreven. Ondanks dat deze persoon doorgaans een zeer ervaren Revit-gebruiker is (en dit is een relatief kleine elite groep), is deze nooit in staat om alle skills van zo’n team te beheersen. Laat staan om in te schatten hoe anderen met zijn oplossing kunnen werken.
De limieten van Dynamo:
- Ten eerste heb je als ICT-beheerder en/of BIM-manager bij een C#-oplossing veel beter grip op de software die de BIM-modelleurs gebruiken. Hierdoor is de kans op onaangename verrassingen veel kleiner dan bij een Dynamo-script.
- Ten tweede werkt een Dynamo-script alleen op het actieve (lees: zichtbare) project. Als je bewerkingen wilt uitvoeren over meerdere projecten of parallel bewerkingen wilt uitvoeren, dan kan dat niet.
- Ten derde is een Dynamo-script echt niet geschikt voor complexe oplossingen. Naarmate het aantal gebeurtenissen toeneemt, daalt het overzicht snel en stijgt de kans op fouten.
- Het bouwen van user interfaces kan zeer beperkt en dit beperkt het delen van een script met derden.
- Dynamo moet altijd als externe applicatie draaien naast Autodesk Revit. Dit in tegenstelling tot een add-in gebouwd op basis van C#-code.
- Ten slotte heb je via C# altijd de volledige Revit API beschikbaar, terwijl Dynamo slechts een beperkt deel beschikbaar heeft.
Natuurlijk kan je op alles een workaround bedenken. Bijvoorbeeld met het gebruik van Python. Echter zodra je met Python gaat werken, ben je feitelijk al tegen de grenzen van Dynamo aangelopen en het maken van een script wordt daarmee niet eenvoudiger (wat wel één van de doelen van Dynamo is!). Overweeg op dit moment zeker om contact te zoeken met een professionele C#-ontwikkelaar!
Er is nog een ander aspect waar C#-oplossingen een betere keuze kunnen zijn dan Dynamo-oplossingen. Op dit moment ontwikkelt Autodesk Forge razendsnel. Een van deze ontwikkelingen is design automation, ofwel ‘Revit in de cloud’. En wat blijkt, mits correct geprogrammeerd kan de C#-code voor een add-in direct gebruikt worden om processen te automatiseren in design automation.
Een ander gevaar schuilt in de tijd. Mensen die met Dynamo aan de slag gaan, zijn zich vaak niet bewust van hoeveel tijd ze investeren in het zoeken naar de gewenste Dynamo-bouwstenen en het schrijven van een Dynamo-script. Het ‘hobby’-gehalte is erg hoog. Het resultaat is vaak leuk, maar het doel om tijd te besparen door te automatiseren, wordt als gevolg hiervan meestal niet gehaald!
Als je processen gaat automatiseren dan doe je dat met het oog op een aantal doelen, bijvoorbeeld: snellere resultaten, consistente resultaten en/of de optimalisatie van processen. Deze doelen bereik je niet als je de verkeerde technologische keuzes maakt. Sterker nog, maak je de verkeerde keuze, dan kunnen de gevolgen desastreus zijn!
Laat je niet verleiden door alle artikelen waarin de schrijver verkondigd hoe makkelijk en snel je met Dynamo kunt automatiseren. De artikelen zijn allemaal geschreven door Dynamo-specialisten, niet door standaard Revit-gebruikers. Deze specialisten gebruiken Dynamo om zeer specifieke projectafhankelijke probleemstellingen te verwerken.
Dus: heb je éénmalig een uitdaging of relatief eenvoudige uitdagingen, dan kun je deze met Dynamo aanpakken. Doe dit dan wel met professionals. Boek bijvoorbeeld één van onze Cadac Experts. Of kijk eens in de keuken bij VIKTOR, één van onze relaties.
In alle andere gevallen adviseer ik als productmanager altijd een C#-oplossing zoals Cadac TheModus!
