You'll Never See Me Saying Automation Is Easy

Even though I am a firm believer of technology

For some reason, I am getting a phone call from Jay.

He’s a client I’ve built a few Dynamo scripts a couple of months ago. The project went well. We solved all the problems, tested the scripts and trained the team on how to use it. I even wrote some documentation for them too.

You know what, I think he’s got a new project for me. You know what they say, when you do good work, good work finds you.

I picked it up and heard his voice come through.

“Hey Braden, the scripts you made for us aren’t working anymore. I swear we followed everything you showed us in the workshop and it’s been working well but it’s now broken.”

Well, that’s not the call you want on a Thursday afternoon.

“That’s weird,” I said. “Are you free for a Zoom call in about an hour? Share your screen and we can go through it ?”

“Yep. See you then.”

So I finish what I was doing and jumped on the call. Jay shared his screen and showed me what was happening. He’d open the model, open the Dynamo script, hit run, and Revit would freeze and soon after, it would crash.

The perfect problem, no error message or warning, just… dead.

Maybe it was the model, so we tried again on a blank model. Same thing. A freeze and then crash. Okay, maybe it was the one of the plugins they had installed. Maybe it was….

This cycle of testing a hypothesis, then crash, then another hypothesis turned the call into 2 hours of agony. For each hypothesis, we had to wait for Revit to restart and well… nothing is more awkward than sitting with a client in silence hoping praying that it will work the next time.

To make things worse, all the hypothesis didn’t work. So, instead of wasting more of Jay’s time. I asked him to send me the model and the script so I could debug it on my end. At least, I didn’t have to keep telling Jay where to click. But he needed this done by Friday and it’s Thursday afternoon.

Once I got the files, I opened the model, loaded the script and hit run.

Do you know what’s worse than things breaking for clients?

It working for you.

I didn’t have any problems, the script ran fine for me. No crash or freezing on my end.

I ran all the scripts across every relevant model I could find from our testing period. And it all worked, nothing was wrong. Maybe there was a setting on Jay’s computer that was causing it. So I shut Revit down, wanting to send him another email, requesting for a call. Mind you, it was 6pm on a Thursday.

That’s when I noticed Revit had an update waiting.

So, I updated it and just just to rule it out, I ran the script again.

And….. shit.

That was the catch. It froze and crashed, just like on Jay’s computer.

It was Revit (If you know Autodesk, this isn’t surprising). An update had broken something in Dynamo. I then spent the night re-writing all the scripts to account for whatever the update had changed. That just meant starting from scratch again and trying to copy the functionality of the old scripts.

It took me about four hours and two cups of coffee to get it done. But on Friday morning, I jumped on another call with Jay and his team. I shared my screen, showed them the new scripts and explained what caused the issue. We tested it on their models, walked through it together, made sure everything was working.

The thing nobody tells you

When I called Jay a couple of weeks later to check in, he was sympathetic to what happened. He was forgiving because he had used the scripts before and it had always pulled through for his previous projects. But when I pushed a little more in the conversation, there was some hesitation.

“So what happens with the next Revit update? Should I call you first? Should we test it on one computer before asking everyone to update? Maybe we’ll just have to run this with a bit more time to spare next time”.

These are questions you start asking after you’ve been burned. When you’re less confident in the tool delivering well. Before that Thursday, Jay didn’t think about any of this. Now he’s worried that an update might break the scripts again. He’s worried that he and his team have to stay late if I wasn’t available.

And if I were Jay, I’d feel the same way. You start second guessing things. Maybe things aren’t as solid as they seem. Maybe next time you run the scripts, you try a small portion first. Or maybe you save a version of Revit on a computer and never update it.

And even on my side, it’s a horrible feeling. Apart from the loss in trust, I didn’t get paid for that extra time (and stress). We were just lucky that I was relatively free that day to handle this emergency fix.

It’s a lose-lose situation, I stay up late fixing something that was stable before and Jay loses some trust. All because Revit decided to push an update.

The reality of building on another platform

But no amount of testing and planning could have predicted this. Dynamo relies on the Revit API, and the Revit API changes when Autodesk decides it changes.

That’s the reality of building on another platform.

And that’s the part when I don’t see people talking about, the maintenance of these tools.

No single tool is a once-off investment. Things in the world keep changing. Revit will update again and that means, some tools will break. The skill then is how you handle the change, not trying to prevent it. That’s why I always say that maintaining a tool is just as important as building it.

What should have happen with Jay, is that when Revit releases a new update, we re-test the scripts again in a non-project timeline. Ensuring that things are still working, if it’s not, then we plan again about how to best fix the scripts and maybe add any missing features we couldn’t before.

Why I take this so seriously

I’ve been on the other side of this too. I’ve depended on tools that have failed me in critical moments. When no one is around to help and you have something to deliver in 4 hours, you plow through it manually because it has to be done.

So even though I make the tools, I understand why people are hesitant to adopt new ones. It’s horrible, being left alone when something you depend on breaks. But the answer is to not avoid tools, it’s to be on top of the changes and handle them well.

So what do you actually do about it?

During development, I still test things thoroughly. I still write documentation and run workshops so everyone knows how things work and why. By the time I hand something over, it’s been put through its paces. Everyone that I work with should have a good understanding of the behavior of the tool. In fact, they should feel confident in it’s robustness and quality.

But testing, in all its glory, cannot simulate a Revit update that hasn’t been released yet. It can’t predict which API function Autodesk will change six months from now.

And that’s exactly why I offer what I call Hypercare support. It’s a retainer for small features, changes and any critical bugs that come up after deployment. It gives you someone to call when things go wrong, someone who already knows the scripts, knows the dependencies, and can diagnose the problem without starting from scratch.

I do this because I can’t predict when a Revit update is going to break something. Nobody can. But I can make sure that when it does, I’m at least available to hop on and fix that error.

If I’d scoped that into Jay’s original engagement, the Thursday night rewrite wouldn’t have been unpaid. And more importantly, Jay wouldn’t have spent two hours watching his screen restart wondering if he’d made a bad investment. He would have just called me, and we’d have handled it. Not to mention, everyone would have been less stressed.

That’s why you’ll never see me saying automation is easy. Because the building part is “easy”. It’s the part everyone on LinkedIn shows. But hardly anyone shows what comes after that. The maintenance, the support and bug fixes when other stuff changes.

Okay, that’s it from me.

If you want to talk through whether automation makes sense for your project, or if you’ve already built something and want to make sure it’s supported, I’m always happy to chat. Reply to this email or schedule a call. That conversation is free.

Thanks for reading
Subscribe to CodedShapes and I’ll send you my free guide on how to actually apply automation to your projects.