Most companies have internal tools nobody’s happy with but nobody will touch.

You know the ones. The tool sort of works, sort of doesn’t. The person maintaining it can see what’s wrong but can’t fix it. Leadership knows it’s not great but won’t approve rebuilding it. So it just sits there, collecting dust or whatever digital tools do when they aren’t used.

The inheritance problem

Here’s how it happens. Someone builds an internal tool. It works well enough that everyone starts using it. It becomes a part of the core process of the company. But then that person leaves.

The company scrambles because they can’t afford to lose the tool, so they hand it to someone else. But when you inherit a tool, you don’t just get the code. You take on all the assumptions, decisions, and constraints that went into building it. And none of that is written down anywhere.

Sure, if you’re lucky, you get a handover. Maybe a few meetings where the original developer dumps information on you. Maybe even some documentation (hopefully readable, not 100% AI-generated). But that only tells you how the tool works. You don’t get the why. Why this approach? What were the constraints? What assumptions were made? What’s the guiding principle of the entire codebase?

All of that is tucked neatly in the head of the person who just left.

So now you’re stuck reverse-engineering intent from output. AI is really good now but even it can’t tell you why things are created a certain way. And when you can see problems but don’t have the context to understand what’s safe to change, you’ve got two options.

Fully Rebuild

Pitch a full rebuild. You put together a business case with a timeline, a budget and reasons why starting from scratch is better. It’s the whole “I can do this better and 10x cheaper” attitude.

But leadership weighs the cost of rebuilding something that “already works but ‘better’” and usually the answer is no.

Add to it

Which leads to the more common option of just adding to it. No refactor, just keeping adding on to the existing codebase. And soon enough it becomes a house of cards because the intent and context of the tool was never communicated.

You’re too scared to modify the core, so you build on top of it. Workarounds, band-aids, adapters, all just to keep the tool running. But each one makes the tool a bit more fragile, a bit harder to maintain.

It’s like a garage you’re afraid to clean out, it’s easier to just keep stacking boxes than to deal with what’s actually inside. But eventually, you’re going to run out of space and have to deal with the contents.

Why this keeps happening

My theory is that it’s a misplacement of our attention.

People only care about a tool twice: when it’s being built and when it breaks. Everything in between is invisible.

The building phase gets all the attention. There’s a budget, momentum and excitement in the air. There’s constant updates on the tool and when it launches, people clap for it because it works and it’s finished.

From that point on, no one actively working on it and there’s no budget for maintenance. Maintenance doesn’t look like work. You can point at a new feature, a launch, a demo. But you can’t point at “keeping something running that everyone assumes just runs.”

The reality is that there’s no “finish” when it comes to tools. They still need to be documented, updated and maintained.

Part of me understands this because if you think about it from leadership’s perspective. They approved the budget. They gave someone time to build it and they’ve rolled it out. Success. The tool is done, so it must be working. Move on to the next thing.

Maintenance is not a full time job and it’s harder to justify it in your timesheet. Which is why it’s often just squeezed in with the other more pressing things. Well, until it breaks, then everyone rushes you to fix it.

What actually fixes this

The real fix here is the structure around it. Software developers, whose full time job is to deliver products to customers, have figured this out. And we can learn from them.

Document the assumptions, not just the code. Most handover docs explain how a tool works. What’s missing is why. Why this approach? What were the constraints? What depends on what? When assumptions are visible, the next person can make informed decisions instead of guessing. This is hard to do after the tool is done, the best way is to document as you build.

Give the maintainer real authority. If someone’s responsible for a tool, they need the power to act on what they see. That means either decision-making authority over the tool’s direction, or a clear escalation path that actually leads somewhere.

Treat tools as living systems, not finished products. A tool isn’t done when it launches. It’s done when it’s decommissioned. Everything in between is active work that needs to be planned for, budgeted for, and respected as real work.

None of this is glamorous and can feel like a waste of money. But it’s the key to long lasting tools beyond a single developer.

The hard part was never building it

Building an internal tool is exciting. There’s momentum, there’s a vision, there’s someone who knows exactly what they’re doing and why.

But that moment is temporary. The person leaves and the tool keeps running on assumptions that no one knows.

The hard part was always what comes after. Making sure the tool outlives the person who built it. Making sure the next person who touches it has the context to make good decisions.

If any of this sounds familiar, that’s because it’s happening at most companies right now. Somewhere in your organization, there’s a tool nobody’s happy with but is critical to how the company operates. What you need is a way to ensure continuity.

That’s the kind of problem I help teams solve. Not just building the tool, but ensuring that it doesn’t fall apart when the people change. If you want to talk about what that looks like for your team, reply to this email or book in a call with the button below.

Thanks for reading.

This is part 3 of the Winton Guest House walkthrough. The series:

• Part 1: Modelling the Fireplace, Living Room and Bedroom

• Part 2: Modelling the Garage and Loft

• Part 3: Modelling the Second Bedroom (this article)

• Part 4: Script Organisation

If you’ve read through Part 2, you now have five of the six structures in your script.

Hopefully, you’ve been building along and giving it a go yourself. Either ways, it’s time to show you how I built the last one.

Before we dive in, a reminder: the best way to learn is to try it and be uncomfortable on your own, then use this guide as a reference against your own. That’s the whole point of these guides.

Okay, without further delay, let’s start.

Read more

Fifteen script versions and 26 versions of the model.

No, not fifteen variations. Fifteen different scripts. And, 25 freaking new models. Each one was created because nothing could be locked down and “something more important” always kept coming up.

Ten months ago, it was the material, we changed from timber to steel. Then, the start of this year, we took out the bracing between the modules. Just last month, we went from 6 columns to 24 then back down to 20.

The best part? We were delivering in a construction stage. Which is typically when things should have been decided. We should be documenting for the actual construction not deciding on parameters.

Yes, it’s a complex project with many moving pieces. Yes, things change, we get new requirements. But somewhere around script number 8, we were no longer iterating, we were starting over again. And again. And oh, again. Oh, wait and again.

The false promise of “it’s just a script”

This client had been sold the dream that with scripts, you move fast even while changes were happening. You know, explore options, generate variations, instant turnaround, that sort of thing. And that’s technically not wrong. But it only works if the core logic of the workflow stays the same.

The videos you see on LinkedIn about sliding parameters and getting new models is true. But it’s not the full story.

There are an infinite number of ways to solve any given problem. So, to say a script can handle all those changes is an unfair assumption. It’s a good tool but it’s not magic.

When you see a model being generated by a script, the output might look the same, but the process is not. Which is why when someone keeps introducing changes without knowing the impact, it can mean the difference between sliding a parameter and rebuilding the entire script.

It’s why I focus so much on the intent of the script rather than the logic of it. With AI and tools like Grasshopper, it’s now possible to solve problems any way you like. What then makes a good workflow is one that focuses on the key principles of the problem. It’s one that aligns to the parameters that are important for the project.

If you’re building a tower and the floor area is important, the design your script around that. Or if you know the client’s data is never clean, trying to create a layer between them and the tool is safer than processing their raw data.

The point here is to identify the overall behaviour of the problem and distill that into rules for the workflow

There are a million and one parameters that you can tweak to solve a problem. You cannot create something that accounts for all of them. So, a good digital workflow is based on the vital ones and uses the rest as assumptions.

Not all assumptions are equal

So, if the problem is that changing assumptions breaks scripts, does that mean nothing can change? No. Things change all the time. That’s the very nature of projects.

But not all changes carry the same weight.

Any changes to the key principles will require a rebuild but “small” changes can be incorporated with little to no impact. The idea is to think of workflow variables as “hub and spoke”. Changing any “hub” parameters has a huge impact, possibly a rebuild. Changing a “spoke” parameter should ideally be accounted for or have little impact.

The point here is that we can’t have an infinitely flexible workflow if we want to make our (normally very) tight deadlines.

So the framework makes sense. But most of the time, no one knows which changes actually cause the most impact. The person asking for the change doesn’t know they’re touching something foundational. And the person who built the script never made that distinction visible. And to make matters worse, the person that accepts the change from the client isn’t always the person that built the script.

But it’s really a communication problem

That’s what this really comes down to. A gap between what the script assumes and what everyone else understands about those assumptions.

When I look back at this project, the pain wasn’t that things changed. It’s that we didn’t have a shared understanding of the impact of changes before it was accepted. No one knew what was priority and what other teams were dealing with. There was a lack of clarity.

The ideal scenario would have been, when there’s a change, everyone should know what that means for both a timeline and a budget point of view.

But even though it’s simple to say, it’s not easy to achieve. In complex projects, there are many teams and some politics that get in the way of clear communication. And understanding the downstream effects can be hard. A director I once worked with put it well:

“On a project, we’re building the plane and flying it at the same time”

It’s hard to understand the effects of our changes because we are trying to make sense of things at the same time.

But we have to try because the alternative is timeline delays, very late nights and budget blowouts. Putting in the work to clarify all assumptions and effects is one of the most valuable things you can do on a project.

So, how do we get better at this ?

The best way I have found is to communicate everything, and I do mean everything. And again, easy to say but much harder to achieve in practice.

It means letting your manager know what assumptions you are making in the script and why.

It means letting the client know your modelling process even when they think it’s not relevant.

And it means that every time there’s a change, you need to bring up why and whether the ripple effect is worth it

Currently, there is no good way to communicate all of this. People don’t read the documents being sent. Some meetings are so long and drawn out that most people don’t even pay attention. Even emails get conflated with people defending their own work or assigning blame.

These days I use a combination of Figma boards, live documents and AI meeting transcripts to try and keep everyone on the same page. I bring these to every meeting. I’ve even sent notes from internal meetings to clients explaining how their change will impact our timelines. That was an uncomfortable thing to do but it’s part of being open and communicating more. The one thing that I have seen some other companies do is play around with AI knowledge agents to help with this.

But, it’s still messy, most projects are. And half the time, I’m reorganizing everything while trying to keep up with the project itself. But it’s better than having all those assumptions in your head and then having them sprung on you at the worst time. And how you do it isn’t really the point. The conversation and clarity is the point. The act of sitting down and saying “if this changes, here’s what it affects” is extremely valuable.

And it doesn’t prevent changes. It just makes the cost of those changes visible before someone assumes it’s a quick update and agrees to it.

Communication is always messy

If you are extremely busy, communicating your needs and impacts is hard. It’s likely not even on your todo list. Leveraging AI has been helpful but it still requires your time and when your deadline is tomorrow, I know every minute counts.

With so many moving pieces, different teams involved and let’s be honest, politics. Being transparent about everything is almost impossible. And trying to do this within a live project time frame makes it even harder.

But this communication debt is something that we don’t talk about enough. We spend so much time learning the tools, Grasshopper, Dynamo, Python, and not enough time learning how to make the assumptions behind our work visible to everyone else.

A vital skill here is knowing which parts of the project hold everything else up, and making sure the people around you know that too.

Fifteen scripts taught me that. Hopefully you won’t need that many.

If this sounds familiar, or you’re in the middle of a project right now, I’d love to hear about it. Reply to this email, or if you want help thinking through how your workflows handle change, book a discovery call.

As always, thank you for reading.

This is part 3 of the Winton Guest House walkthrough. The series:

• Part 1: Modelling the Fireplace, Living Room and Bedroom

• Part 2: Modelling the Garage and Loft

• Part 3: Modelling the Second Bedroom (this article)

• Part 4: Script Organisation

If you’ve read through Part 1, you now have the Fireplace, Chimney, Living Room and Bedroom in your script.

Hopefully, you’ve read the the brief and have been trying to model this on your own too.

Before we dive in, a reminder: the best way to learn is to try and solve it on your own, then use this guide as a reference. That’s the whole point of these guides. To give you a problem / project to anchor your own learning to.

Okay, without further delay, let’s start.

Read more

I’m on a call with Jack. We’re going through the analysis model for what seems like the 300th time.

“Try reducing the size there, oh and we need to ensure we have the right beam releases. Can you also just put in a simple truss here?”

I am frantically clicking away trying to keep up with the changes that “we” want to make to the model. After about 15 minutes of silence (which is a very long time on a call), I re-run the model and Jack unmutes himself.

“Okay, we are getting closer. Can you try reducing the loads on level 10 to see what happens ? Also, can you add a new freedom case in to mimic the stiffness of the floors ? Let me give you the spring values”

So, I do what he asks and this time, 20 minutes go by before we look at the model and try some other modifications again. None of these are big changes, they are Jack experimenting with different analysis parameters to get the model to work. It’s actually the kind of thing I do with my scripts and programs. He needs to see the results of all these changes to get a sense of the model and to know what to try next.

So, this is what an LLM feels like.

Nothing I do here is computational. Yes, I am learning a lot about what makes a good structural analysis model but is that really the best use of my time here? It might help me write better scripts in the future but right now I’m just clicking where I’m told to.

Jack knows exactly what he wants. He has the structural expertise, the intuition for what to test. . So why isn’t Jack just doing this himself?

Well he has no idea how to use the current program, so I become his hands because I made the script that created the model. And aside from this inefficient way of working, there are two things going on here and they’re easy to confuse because they look the same from the outside.

The wrong analysis program

This entire thing started because of the complexity of the model. Jack reached out because the geometry was impossible to do by hand.

So, I decided that Grasshopper was the best tool to generate the geometry. And at the time, the only analysis program that would work well with Grasshopper was a program called Strand7.

But, Jack was not a good Strand7 user. He knew how to extract data from it and spin the model around, but he could not use it well. I, on the other hand knew the program quite well because of it’s connection to Grasshopper.

Jack reassured me a few times that the analysis we needed to run was simple. It was a proof of concept and that everything could be done through the script. Not manual changing or prodding required. What he needed from me was an understanding of the geometry and some basic loading given his client’s constraints.

Well, the client loved it. But we never change analysis models. The Strand7 model is now really complex. Packed to the brim with freedom cases, restraints, beam end releases, etc. All done manually on the analysis side. In fact, there was little to no Grasshopper work anymore because all the changes and additions we made to the model were normal structural engineering changes.

It was at this point that we should have paused and re-evaluated if this hybrid of computational and manual approach was still the most effective way of working. Where it’s no longer a proof of concept but rather a fully featured structural analysis model that should be managed by someone else.

Because the amount of manual changes that Jack could have done on his own has surpassed the benefit of using Grasshopper. In fact, it got easier to define a split between scripting and manual fixes because we moved from geometry to analysis as the project evolved.

By planning that, we would have come up with a much more efficient way of working. Not to mention the experts in analysis would be able to make changes to the model without having to contact me all the time. I wouldn’t have been on hour long calls with Jack just for him to tell me where to click and what numbers to put in.

And if we ever wanted to bring some scripting functionality back in, I’m sure we would have found a way with Grasshopper. Maybe creating the model in Rhino, then importing it in and applying the loads. At this point, we should have stopped and re-evaluated our options and what it was costing us by staying with this workflow.

Accidental ownership

The second cascading problem to this is me “owning” the model.

Because it came from a Grasshopper script, everyone was asking me to make changes and review them. Me, the person that hasn’t done a lot of structural engineering work and has pretty much rote learned it by making tools for people. Combine that with the fact that Jack can’t use the program well and you have now made a bottleneck. You now have someone under qualified making changes in critical areas.

The ownership of the model became a by-product of using a script and from choosing the wrong analysis program. It’s the part that bothers me the most because accidental ownership is the kind that’s hardest to undo. I can’t one day just say that I am not making changes anymore.

And this isn’t a one-off. I’ve seen the same thing happened a few times. There was this one tool that I build in Grasshopper to run vibration checks and suddenly, I am the “vibration guy”. Everyone came to me for help on why their models weren’t working or why they didn’t get the results they wanted.

just because I made it, I suddenly own the space surrounding it

In both cases, I ended up owning something that should live with someone else.

Hindsight, and the uncomfortable conversation

Maybe it’s the hindsight bias talking, but I should have pushed back more. I should have had this conversation with Jack and ask more questions about ownership and process. Things like who makes the manual changes, should we change programs, or do we need another engineer to help us.

It would have meant asking questions he might not have been ready for or might not have known the answer to yet. “How complex do you think the analysis side will get?” is not a question anyone wants to hear when they’re just trying to get the geometry into a model.

And the real skill is knowing when to introduce friction. When to set boundaries with people.

Pushing back when you’re given work is uncomfortable in the moment. Especially when you always want to go a good job with people. Pushing back creates the friction that slows things down when everyone just wants to get started. It’s hard to be that reason things aren’t moving as quickly.

But the alternative is hundreds of long calls where I am just clicking where Jack is telling me to.

When you’re too busy to set boundaries, that’s when you need boundaries the most.

If you’re about to kick off a project and you’re not sure how automation or computational stuff will fit in then that’s the kind of thing I help people think through. Reply to this email or book a discovery call. Even if it’s just to talk it through and nothing comes out of it, the conversation is free.

This is part 1 of the Winton Guest House walkthrough. The series:

• The Brief

• Part 1: Modelling the Fireplace, Living Room and Bedroom (this article)

• Part 2: Modelling the Garage and Loft

• Part 3: Modelling the Second Bedroom

• Part 4: Script Organization

If you’ve read through the brief, you now have everything I had when I first started. The reference images, a sense of where the six structures sit in relation to each other, and my modelling approach.

Hopefully, you’ve given it a shot or are in the process of trying it yourself.

Either way, it’s time to show you how I built this.

Before we dive in, a reminder of the principle I want to keep coming back to throughout this whole guide: the best way to learn is to try it and be uncomfortable on your own, then use this modelling guide as a reference against your own. The whole point of these guides is to give you context and a problem to anchor your learning.

Okay, without further delay, let’s start.

Read more

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.

Previously, I wrote about why learning with a real problem in front of you is different from any tutorial. But it’s not good enough for me to just say “go find your own problems to solve”. So, this is the first article in rectifying that.

It’s the start of me giving you a real problem to work with in case you don’t have your own.

Below is everything I had when I started modelling the Winton Guest House. Treat it as a brief. If it helps, think of it as an assignment. Go through the reference images, do some googling of your own and read the modelling approach I have taken.

Then, when you’re ready, start modelling it on your own.

Yes, I know that can be scary and it can be overwhelming but that’s part of the process and the learning. The struggle is how you earn to look at something and build a Grasshopper script from it.

Then, when you are truly stuck or maybe you’ve made your own solution, reference it to mine. In the coming weeks, I’ll be publishing a modelling guide that shows the script I made. It’s my answer to the brief.

The Winton Guest House

It consist of six distinct structures, each with its own type of geometry.

To make sure we are on the same page, here are the names and locations of each structure:

And the plan view, which, to me, is the most useful reference for setting out the geometry:

If you do need more information, you can always find them online.

My (recommended) approach

When I look at a building I have never modelled before, I am not thinking about the architecture. I am looking for the logic. Where does this start? What depends on what?

The Winton Guest House has a clear one to me.

The fireplace is the anchor. Everything else in the script works from it in some way. The chimney grows out of the fireplace. The living room grows out of the fireplace. The garage grows out of the living room. The loft sits alongside the garage. The second bedroom is the last piece to slot in.

Of course, if you do want to start from another building like the living room, please feel free to

Once you see that flow, the model becomes one problem with six big steps, each one using what came before it as its starting point. That order is why the guide starts with the fireplace rather than whichever structure looks most interesting.

The fireplace is really just a box with another taller box on top that makes the chimney. The roof of the living room is a trapezium and the rest are also combinations of simple shapes with the exception of the bedroom. So, leave that for last. And if you get really stuck on that, part 3 of my guide will show you how I did it.

Start now, don’t worry about perfection

You do not need to get everything right, and you do not need exact dimensions. Focus on the relationships between the structures rather than precise measurements. What we want from these modelling challenges is for you to build the instinct of creating your own workflow and pulling components to solve problems.

When you are ready to compare notes, or when you hit a wall, the modelling guide is split into four weekly parts:

• Part 1: Fireplace, Living Room and Bedroom

• Part 2: Garage and Loft

• Part 3: Second Bedroom

• Part 4: Script Organisation

Each part has a script file so you can check your work section by section. Part 1, starts next week.

But as you go through it, remember that my approach is just one way. There is no “ultimate“ way to model this. But we all have to start somewhere, so if your script differs from my guides, it’s okay. We’re just getting the reps in.

Happy scripting!

There’s this satisfying feeling that happens after you finish a tutorial or a lesson in a course.

You know what I mean. You’ve watched the whole thing, maybe you’ve followed along, maybe you even took some notes. After that, you’ve definitely mastered “data-trees for Grasshopper”.

So, why is it that when you open up Grasshopper on your own, the only thing you can do is stare? You should have mastered this, you watched the tutorial. You even took notes. But all you have are more questions.

What components do you use ?
How do you even start, a point ? a curve ?
Where’s the list to graft ?

If any of that sounds familiar, it’s because it’s the classic “I don’t know how to apply what I’ve just learnt to the real world” problem. That’s why even after 4 years of going to Unviersity, most people will still treat graduates as “starry eyed fledglings”.

I have written about this a couple of times now. One piece was about why I would learn Grasshopper differently if I started over. Another, was about the moment the tool finally made sense to me. And this one was about why learning through tutorials only won’t get you very far. I even made a LinkedIn post about it.

The TLDR of all of them is that tutorials and online courses teach you what the components do and where they are. But they don’t teach you how to use them to solve real world problems. That part only comes from getting more experience.

The responses I got from those pieces told me that a lot of people understand this. They have done the tutorials. Understand the material in the moment. And then nothing transfers to their jobs. They can take every “masterclass” under the sun and still feel like they are starting from scratch every time they open Grasshopper.

Context is key when learning

I got lucky because my job at the time gave me context while I was learning Grasshopper for the first time. I had a real task with real deadlines and a real manager to hold me accountable. He was also a manager that would occasionally pull up a chair when I was completely lost and say, here, think about it like this.

He gave me direction, so that I wasn’t completely lost. He gave me some breadcrumbs to follow. But I still had to find my way there. It was still up to me to learn the right techniques to solve the problem.

I did end up learning the fundamentals of Grasshopper though. But not because a course told me to, because it was the only way I was going to solve my problem. I had to learn about data-trees because my situation demanded it. I wanted my scripts to work well and for that, the fundamentals are important. But doing it for the sake of doing it is how you get so bored that you rather run into a wall.

Learning in context is different to your regular online course or tutorial. Because it means you have to intentionally get lost and find your way back on your own. Which can be an extremely uncomfortable feeling, especially if you’re paying for a course to be reassured you’re on the “right” path. It’s weird to say “I am buying this course to feel lost and find my way back”. It’s much easier to buy a course that spoon feeds you problems and answers.

But all you’re doing is accumulating carnival cash. It feels great in the moment but means nothing in the real world.

The part that is hard to replicate

The problem is that most people learning Grasshopper today don’t have access to their own problems. They have jobs, but Grasshopper is not central to them yet. Or they are students, or they are trying to upskill before a role that needs it. They can’t find their own context to make the learning stick.

Telling you to find your own problems doesn’t help if you don’t know what can be done. It also doesn’t help if it’s too overwhelming to go through it on your own. I even made a course on how to find your own problems but it still doesn’t help if you are very new at this.

So, I have been trying to figure out how to give someone that project experience if they don’t have one? How do I structure a problem in a way that is not too overwhelming, that challenges you and still gives you enough direction?

The inspiration of modelling challenges

That is what I am trying to build here. A series of modelling challenges that give you that context for learning and forces you to come up with your own workflows.

Okay, why modelling?

For starters, I think it’s the most common use case for Grasshopper. I also think it teaches you the most about how the tool works. From there on, if you wanted to branch off to urban analysis or optimization, it’s not a huge leap anymore.

I know how overwhelming that all sounds. But the point here is to challenge yourself to come up with your own way of solving problems. That’s how you build that instinct.

So, if you’re interested in getting some reps in for Grasshopper or you want hone your skills, I encourage you to join me.

We are going to start with a model brief which is basically summary of what you are going to start modelling. In the brief, you’ll have reference images, how I would model it and also what to look out for. Then, you just have to start.

But I did say that to learn effectively, you also need direction. Which is why after you’ve tried or if you’re feeling extra stuck, I’ll be publishing a modelling guide too. It’s basically my “answer” to the brief.

It’s not like I am giving you a problem and then leaving you alone. I am going to solve it too and show you how I did it. Mostly for you to reference and compare against your method. The key here though is that you have to try and solve it on your own first.

P.S. if you’ve never opened Grasshopper before, I’d suggest going through my primer in Grasshopper first to get up to speed on the basics. It’s only six lessons and it gets you to the point where you can read a script and know what you are looking at. Start there and come back.

What we are working through

Starting tomorrow, I am introducing the first building we are going to look at: Frank Gehry’s Winton Guest House, completed in 1987. It’s six distinct structures, each with its own geometry.

I chose it deliberately because it is complex enough to be challenging. But it also has a quality that I think makes it a good teaching vehicle, there is a clear logic to the order of things. Each part of the building follows what came before it.

The brief will walk through what the building is, how I see the building in terms of “plan of attack” and how to approach modelling it. Think of it like a mentor giving you a task and some direction and your job is to use Grasshopper to solve it.

From then on, there will be four parts to the guide, published every Tuesday for next few weeks. Each guide also comes with a script, so you can see how the solution progresses along with my thinking. And they are all available for paid members of CodedShapes.

If you are on the fence about subscribing, this might be a good chance. You can always subscribe to learn from it and then quit after you got what you needed, no hard feelings at all. The pool of resources will always be here.

Closing thoughts

Learning in context is one of the most effective ways I’ve found to learn. After going through it, it’s hard to imagine ever sitting in a classroom or a tutorial learning for no reason. With anything that I am trying to learn (Grasshopper or not), I always anchor it to a problem/project.

This though, is a much harder way of learning and the effort you need is a lot higher than just kicking back and watching tutorials. Just be mindful of that. But that is the point of all of this. I don’t want you to memorize things for the sake of it, I want to give you a reason and some meaning to it.

The first model brief is now live!

Check it out here :

I was part of a digital team that built an analysis tool for a project.

It managed data between a main model and many sub models for structural analysis. The idea was for each engineer on the team to work on their own model, then use our tool to combine everything into a single main model. It made modelling collaborative which if you know how analysis programs worked, was a big deal. Most, if not all analysis programs only allow one person at a time.

That meant the project team could put almost every engineer (junior to senior) on the modelling without having to copy and paste between models. This was actually where most of the errors and problems come from. People model the paste the wrong thing or they accidentally delete something important in the main model.

But with our tool, a click of button would solve all of that. You’d get a team-built and expertly led analysis model as many times as you needed.

It was so good and we wanted to present it to other project teams. The hope was that they, too, could experience the future of modelling through the same system. Even though our tool only worked for this project, it wouldn’t have been hard to tweak it for others. In fact, with enough motivation, we could build the same system for everyone. We were creating collaborative editing for models

So, present we did. Hoping to get more interests and ideally, more funding. For 30 minutes, everyone watched us explain this magical process. Parallelize the modelling, click this button, and have all your complex analysis woes solved.

At the end of it, all I could think was: “This is why no one trusts us.”

Because the truth hurts

The tool actually made the project worse.

The one-click reality was people still had to manually copy and paste between models. The very thing the tool was designed to prevent. But now, they also had a tool that would get it wrong, so sometimes, they had to spend even more time cleaning up after the tool.

To make things worse, after we made the tool, there was also a period where the original developer who built the tool was on leave. He didn’t give any handover notes or access to the original code. So, when the tool broke and there was no one around to fix it. I helped out the project team by also manually copying and pasting between models. Not fixing the tool, actually placing lines and copying numbers. Again, the very thing the tool was designed to prevent.

Before we showed up to this project, the team had a workflow. It was manual, error prone and slow, but it was theirs. They understood it and knew exactly what to do. Now, they had a tool they didn’t fully understand, that occasionally saved them time and occasionally broke at the worst possible moment. So, they ended up with a workflow that was slower, more error prone than just doing it manually.

Now, imagine you’re a manager. You’ve been promised that you get a tool that would almost half your turnaround time. What do you tell the clients?

Well, you tell them you can do it faster.

Which is exactly what made the deadlines of this project so tight. The team was depending on the tool working. They’d planned a tighter turnaround because the tool was meant to handle it. But because the tool broke so often and the team weren’t available, they dug their own graves. They had to work long hours to make up the tight deadline that the tool was supposed to prevent.

And after everything, we still presented it to everyone like it was the next best thing since sliced bread.

I bet the project team were laughing at us during the presentation. They would never work with the digital team again. I mean would you ?

That feeling must have bled to the other teams too. Because as “game-changing” as our tool was, no one reached out to us. I swear we looked like clowns up there. The tool also never saw the light of day again.

We sold the dream, not the reality

The thing that bothers me most about that presentation isn’t the overselling. It’s the eroded trust with the team.

The project team trusted us. They built their entire schedule around it. They told their clients they could turn things around faster. They took on tighter deadlines. They made commitments based on our promises.

They basically believed that we would together to deliver a product that was better than the sum of it’s parts. And we let them down an threw them under the bus.

And while they (and I) stayed late delivering the project while the tool broke, we still stood up there and called it the best tool.

That’s no longer overselling, that’s taking someone’s trust and using it against them.

I don’t blame people for not trusting the team again.

Then we disappeared

But the biggest crime isn’t the broken tool. It’s disappearing after you’ve sold the magic. Especially when people have build their deadlines and budgets around it actually working.

The guilt from this project still stays with me.

There were days where the project team needed help. The tool broke, which was common, but our team had moved on to other things.

I remember our replies all fell along the lines of: “Yes, that’s a bug, but I’m busy. I’ll get to it in 2-3 days.”

But they had a deadline tomorrow. So they stayed up that night doing things manually. And eventually, they stopped asking.

The kicker? When we finally had time to look at it, we’d say something like:

“Oh, you shifted the geometry. Our tool doesn’t support that. So, you broke it.”

The tool broke and we didn’t fix it. They still had a deadline, so they fell back to the manual way to get it over the line. And then, when we did have time, we blamed them for breaking the tool that we made.

If that happened to you, how hard would you kick us?

Two sides of the same coin

Of course, it’s not always this one-sided. There have been times where there are bad inputs or assumptions. Or people try to use the tool outside it’s design and expect it to perform magic.

But the common piece on both sides is trust and reliability.

Trust goes both ways. You need to trust that the tool will consistently deliver. And I need to trust that you’ll use it within the agreed conditions.

Reliability also goes both ways. Before I completely handover the tool to you, we have to ensure that it’s tested well and that you’re confident it works the way you need it to. Of course, there is another piece that when something breaks after, I’m there to fix it, not leave you hanging.

If you can’t trust or rely on the digital solution, then nothing will go well.

We have to align on the direction

I still think computational design is worth it. I wouldn’t be writing this newsletter if I didn’t. The time savings are real, and the problems we can solve now are genuinely amazing. And the whole idea is to build something better than the sum of it’s parts.

But we need that trust and reliability on both sides first.

We can’t sell magic and then disappear when it breaks. And we can’t expect our tools to solve every problem when the only instruction was “fix it for me”

The way to close that gap isn’t to be more impressive. It isn’t to use more AI. It’s to be more reliable and honest about everything we make, like what it can do, what it can’t, and what happens when it breaks.

Thanks for reading.

If you’ve used Grasshopper for anything remotely complex, you’ll know how annoying it is when you open the script and forgot to lock your canvas.

Even worse is if you’ve forgotten a stream of components that take a lot of time to run and you accidentally “resolve” the canvas.

Obviously, I’m speaking from experience here.

A small but vital component is the False Start Toggle.

It looks like an ordinary Toggle but defaults to False all the time. That means when you restart your script, the value of the toggle will be False.

Now, why?

Well, like a data dam, that means you can actually choose when to run things in Grasshopper instead of having it run all the time.

The biggest difference between the false start toggle and a data dam, is that I don’t have to click on it every time. I just have to do it when I restart my script.

Where to find this ?

Like most things, it’s a plugin and it’s actually part of the entire suite of components in LadyBug.

Which yes, I know it’s annoying to install the entire suite of tools just to get the False Start Toggle. So, I’ve actually separated it out for you.

I’ve attached the standalone component file below. You can drop it directly into your Grasshopper libraries folder without installing anything else.

→ Get the False Start Toggle here

I hope that helps.

Thanks for reading.

About a year ago, a site coordinator came to me with a request. Let’s call him Marcus.

He was confident, specific, and he knew exactly what he wanted. That’s actually a rare case. Most of the time, people know they have a problem but they don’t know what they need to solve it.

Marcus wanted a script that colours panels in a Revit model based on their installation status. His company was installing panels across a few storage warehouses and he wanted to know the statuses of the panels. The current workflow was every day, contractors on site would update an Excel sheet with that status. Marcus would then review that status but it was hard to know where those panels actually were. I mean they had IDs but how do you know where those panels actually are ?

So, he wants a script to read it and update the colours in the model.

I remember thinking, oh, this is straightforward. He’s already done the thinking, I just need to build it. The problem was clear and the solution made perfect sense. We signed. And a week later, I showed him the script.

Marcus nodded. “Yeah, that’s cool and all, but how do I see what the panels the contractors last installed? I need to see if we are on schedule”

I replied, “Uh.... you don’t. This reads the Excel sheet and colours the model. Like you wanted.”

“Okay, but I need to see which panels were installed before and which are installed today”

It turns out what Marcus actually needed was a way to retain the history of installation not just show the status of the panels. He wanted to see movement and statuses over time, not just update the model with the latest information.

The script worked perfectly. It just solved the wrong problem.

It would have been easy to blame Marcus for not communicating properly. But I also never asked why he needed to see the install statuses in the model. I didn’t ask why he wanted that information. He only told me after seeing the script for the first time.

I got lucky though. The rework was a straightforward addition. But if Marcus had wanted the site contractors to run the tool, or if there were more complex requirements buried in that brief, I would have been rebuilding from scratch. And I would be having an awkward conversation with Marcus about the fee.

Walking Into the Middle

This is, unfortunately, a more common experience that I would like.

Digital projects almost never start from a blank slate. Normally, someone already has some ideas about what should happen but they may not communicate that to you because it’s “common knowledge”. And if we take them at face value, we might end up building something completely off the mark.

I remember another time where I walked into the middle of a client’s political debate to switch from using Solidworks to Tekla Structures. I was told to write two proposals for two different programs because they wanted to understand the impact of switching programs.

To them, it made sense. Get the expert to vet the processes and then figure out which is the better option. But they wanted two proposals written up in a week without any additional meetings. They said “it’s all common sense”, so this should be easy.

But I am not apart of their processes, what may seem like common sense to them are assumptions and decisions that I don’t know. So, it was damn near impossible to come up with accurate requirements.

There’s always more than meets the eye

The better the work looks, the easier it seems. And the easier it seems, the more likely you will build the wrong thing.

“Just add this” is never just adding a feature. If something sounds too good to be true, we have to stop and assess whether there are any other hidden complexities behind it.

Of course, we won’t be able to predict everything but we can’t be too reductive about complexity. Especially, when we aren’t steep in their environment.

It takes two to build the right thing

I had another client who wanted a plugin in Tekla. The brief was was also clean, go from a quotation spreadsheet to a 3D model. And their instinct, like Marcus’s, was to fast track things. Give the fee, the timeline, approve it, and let me handle it.

After having learnt my lesson with Marcus, I reined it in and asked more questions.

It was uncomfortable because it seemed like I was skeptical but it was actually because they didn’t have a clear picture of what a Tekla plugin meant for their workflow. I was worried that they were developing their workflow and plugin at the same time, which is never a good idea. A good plugin needs to be embedded into a process not a new one.

After some pushing and prodding, we finally agreed to a discovery phase first. We went through the spreadsheet together. We explored what deployment would look like. We even checked if another program was a better fit.

And two things came out of that phase that we couldn’t have found on our own.

First, they were already working on a new version of the spreadsheet. If I’d built the plugin to the existing one, it would have broke within months.

Second, they had only one Tekla license, which meant only one person needed to run it. That cut the deployment complexity significantly because I didn’t have to worry about company wide IT policies yet.

We ended up waiting two more months to build the plugin. And, I’m glad that we did because it ended up being more stable and much closer to the workflow they wanted. The overall delivery was slower but it was more intentional and more valuable to everyone.

You want a discussion not instruction

The best tool or script isn’t one person building exactly what the other person asked for. If you want that, LLMs are getting really good at that.

It’s actually, two people figuring out what should actually be built given the situation and the problem.

That starts with a client who’s willing to share the context, not just the brief. And a digital person who’s willing to ask, not just build.

I once had a script for a project that I had over five data streams to maintain.

I am sure you’ve been in the same boat before.

You have the your geometry. Then, say a property, like an area. Oh but that’s not enough, you need to know which geometry is made of steel or wood. Then, you also need to know which geometry has to be cut and which hasn’t.

Sorry, for the rant. The point is when we work with geometry in a script, it’s never just the geometry. We always have some other information that we need to bring over too. And if you have a complicated script, your data structure is normally..... quite complicated.

Typically, in Grasshopper fashion, we would just copy and paste this structure as many time as you have information. So, 5 properties means 5 data streams. Maybe you have a script that looks like this.

Now, imagine you update the script. You have to remember to update all the streams or else the script breaks. This is actually why scripts become brittle.

Is there a better way ?

Yes, yes there it.

And it’s a technique that’s been in software development for a long long time. It’s called “Object Oriented Design”. It means that instead of our geometry being just a curve or a line, we can attach some information to it known as metdata.

This means, instead of just the geometry, we have an “object” that has everything we need. This is also known as a “container”. So, instead of using multiple streams of data, we can put all of that in a single stream and carry that around with us.

If I didn’t have this component with me. I would have an additional five streams I need to maintain. Having fewer streams just means less to maintain later on.

Also, if you do work with other people, you can bake the metadata into Rhino as well. This means other scripts can use the same metadata. It also means people can see that metadata in Rhino. This is something I talked about in my article on Elefront.

Options to do this

Okay, so how do we do this in Grasshopper ?

We actually have three choices here.

Read more

Right now, you’re reading this article. Or at least starting to, but before that you might have been scrolling on Instagram or even LinkedIn.

I know at least, Jay was. He’d been active on LinkedIn for months. Following every computational designer he could find, curating his feed to see how others have used computational design to automate away 90% of their work. Sipping mai tais while pressing a button then charging their clients 100 hours for it.

Then, he takes a look at his own work. He spends 10, maybe 20 hours a week just entering data that his juniors can’t seem to do well. His IT team blocks him on any new program he wants to try. No new LLMs, no new software, it’s an invasion of our privacy, says the IT team. Most likely upper management.

On his latest project, while modeling things manually in Revit, he really feels the gap. Everyone else on LinkedIn is doing cool shit and he’s here drawing lines. He, too should be sipping mai tais while AI does the work for him.

So, he goes back on LinkedIn, sees the latest computational design post, and decides to reach out. Maybe someone can show him the promised land of automation, that way he doesn’t have to work so hard. And that’s how he finds me.

We go on a call. He shows me his current problem, he’s manually modeling facade panels on a tower. The geometry isn’t that complicated and realistically they vary only a little with each floor. But there are 68 floors. So doing it with a script? Easy. Manually? A pain in the ass.

Before we end the call, he says something peculiar.

“I want to run the script, can you just give it to me and show me how everything works?”

I said yes. And my thought was, Jay was a great client. Most clients just want the result. Most of the time, I am just sending them the model, not the script. They don’t care about how it’s done. Jay wanted the script which was a first for me but I happily agreed.

So, after the contract was signed, I spent the next week writing the script. And when it was done, I went on another call with Jay to show him how it all worked. And since he wanted the script, I tidied the script up and sent it to him.

Jay lit up when he saw me press a button and all the panels were modeled. He was in the promised land. He was ecstatic.

What a great client, he’s happy. I’m happy.

Two weeks later, I get a message from Jay.

“Braden, your script doesn’t work, I tried to run it on another model and nothing comes out”

We jump on another call and Jay shows me what happened. He was trying to run the same script on a different model.

I told Jay that the script only works for that model. That was what we agreed to. A geometry-based script works for the project it was built for. It doesn’t just put panels in for every model he has.. He grunted and asked how I can fix it.

I mean it at least was still a tower and it was a pretty simple fix from what I could see, so I just did it then and there for him. And it worked.

But, he pulled up another model.

“Can we try and run the script on this model too? And if it doesn’t work, can you fix it?”

This time, the model wasn’t so simple. The change to the script wasn’t small. I told him I would need more time and a variation to our initial contract. Jay wasn’t happy.

“But on LinkedIn, I see so many people doing cool shit with Grasshopper. Why doesn’t this just work ?”

I told him as gently as I could that this isn’t magic. There is still work involved. Yes, it can save you time and produce things at scale that you can’t do manually, but it still takes time and skill. Nothing is ever as easy as it seems.

Jay wasn’t wrong to expect what he expected. He made a completely reasonable assumption based on everything he’d seen. The posts on LinkedIn showed scripts working. They don’t show the two hours someone spent cleaning up the inputs. They don’t show the effort it takes to format and sanitize the data before the script. And they sure don’t ever show when scripts actually aren’t useful.

And I’m part of this too. Every demo I’ve ever posted always comes from success stories. And as much posting about my mistakes that I do, it’s the successful ones that people are drawn to.

It’s actually why on both LinkedIn and here, I’m trying to be more grounded. To show the mistakes and the real experiences behind these things. Although in doing so, I still get annoyed at the occasional post about people “having fun all the time” on LinkedIn.

Because clearly their automation is not the same automation I’m doing.

There’s no promised land

That’s probably the most misunderstood thing about computational design. People think automation smooths things out. It doesn’t. It actually makes every inconsistency jarringly obvious.

When you do something manually, you adapt without thinking. You see a different setup and you just adjust. You notice the geometry is off and you work around it. The biggest lesson I’ve learnt is how much we’ve come to rely on our human judgement for things.

While that is what makes us valuable, it’s something that is hard to scale. A script does exactly what you told it to do. And if it sees “column 01” and “column___001”, it won’t know the difference. I know things are different with AI but for the most part, that principle is still the same.

To me, that’s actually a feature. It’s telling you that your inputs or process aren’t as consistent as you thought. Like maybe you thought everyone has been putting things correctly in the right place, try to automate something and you’ll immediately find out that human driven processes are not consistent.

But nobody frames it that way. And most clients don’t want to hear that their process has problems. They just want the script to fix things, go faster and reduce cost.

Jay thought it was one script to rule them all. That all he needed was to make one script and all his problems will go away. And it’s a bitter pill to swallow when you find out that there is no promised land. That there is no single automation that will make life easier. Nobody reaches out to a computational designer hoping to be told “actually, your real problem is your model setup.” But it’s the truth more often than not.

I don’t say this to blame anyone. Most teams have never needed consistent model setups before. When everything is manual, inconsistency doesn’t matter because again, we have human judgement. It’s only when you try to automate that these inconsistencies become painful.

So what do you actually do?

I know that’s not what people want to hear. We want the shortcut. We want to skip the messy middle and land on the clean result. We want the thing on LinkedIn to be the thing we get. We want plug and play.

But there is no promised land.

I still get impressed by the LinkedIn posts especially if they have managed to scale it because I know the effort it takes to make that happen. And it’s really all the unsexy stuff that doesn’t get likes but makes everything else work.

I can’t pretend I always get this right either. I still catch myself going straight into build mode before I’ve asked enough questions about the problem / data.

I know, if you’re a client, you may not want to hear this because I am meant to make your life easier not harder. But from experience, a two sided conversation about how the automation complements the ideal process always creates a better result.

So, if you want to think through whether automation makes sense for your situation, I’m always happy to chat. Even if it’s just to figure out whether the problem is the process or the tool. Reply to this email or book a discovery call. Having the conversation is always free and it will point you in the right direction.

I once had a Grasshopper script that produced three separate parts of the same a model. Like a car where you have the doors, the body and the engine. They are technically part of the car but are detailed enough to be treated individually.

Okay, I needed to export multiple parts because I have a single, pretty complicated script that produces the models.

So, for the first few times, I did the export manually. What’d I do is bake all the parts from my script into Rhino, then select each part and then export them to individual files.

It was manual and quite annoying to do. So, by the third time, I had enough.

I did some research and found a way export these files through Grasshopper instead of manually
doing it. It’s now one of the small workflows that I have in almost every geometry creation script.

If you’re a paid member of CodedShapes, you get access to the script below along with my other courses, guides and templates

Subscribe now

How this works

They key thing about this workflow is leveraging Rhino layers.

The first things I do is use Elefront to bake objects into the right layers. Then I select those objects in Rhino and export them into their own files. The best part is that the export component let’s you select the format.

This is important because using Rhino layers means I don’t have to re-wrangle my data structure to meet the export structure.

Like if my data-tree is structured per material (e.g. steel, rubber, wood) but I need to export per part. Using the Rhino layers is a good way to bridge that without polluting the original structure.

The script

Okay, so if you’re a paid member of CodedShapes, you get access to the sample files below. You can see how I am using this workflow in some of the past projects I have worked. If not and you’ve been wanting to learn more Grasshopper, this might be a good time because a membership gets you access to courses and other resources too.

Read more

I remember this one call I had with a client. Let’s call him Adam.

yes, I am starkly aware that most of my articles these days start with a call

It was a kick-off call for Adam to brief me on a modelling package. Showing me the current model and what my part of the modelling looks like. But five minutes in to the call and Adam couldn’t get the model up because he had some problems with his network.

The call didn’t drop off but he was frantically trying to turn his VPN on to get access to the model.

“Thanks for being patient, there’s always so many steps to turn on this darn VPN. It always resets when I walk into the office” he said. “I have to keep toggling it whenever I leave the office”.

“No problem”, I said. And I spent the next ten minutes or so watching him fumble with the settings.

I did notice that I think there’s something that can be built to make his life easier. Maybe something that he can click and it just turns the VPN on/off for him without going to settings → network → advanced settings → turn VPN off all the time.

He eventually got the model opened and we went through the modelling package. But I also left that call with a curious idea that I could build something that solved this VPN conundrum of his.

A few moments later

About a week later, we had our update call as scheduled.

I started with: “Hey Adam, before we get into the modelling update, I noticed something in our last call and I made something small just to help you out, would you test it? If I did things right, it should toggle your VPN for you, so you don’t have to always find the setting.”

Adam opens the executable and just double clicks it

“Oh, shit! That’s pretty amazing, that saves me so much pain. It’s always so annoying to find that damn setting,” Adam said. “I didn’t even know you could make something like this. I thought you only do Grasshopper. Heck, I didn’t even know this was a problem that could be solved.”

That last part stuck with me. He didn’t know what was possible.

That modelling package went well and Adam has been a repeat client ever since. And now that he got a glimpse at what I do, the work that I have gotten from him has varied from regular modelling to creating plugins and standalone programs for him and the entire company.

Subscribe now

The problem with “computational design”

Seriously, one of the hardest parts of what I do is telling people what I do. I can’t just say “Grasshopper.” I can’t just say “BIM” or “software developer” either.

When Adam hired me, he hired me for Grasshopper work. Parametric modelling. That’s what “computational design” means to most people. Geometry, 3D models, and magic.

He didn’t come to me because of his VPN. Well, he didn’t even know a tool could be built to solve that problem. And he didn’t know I could solve that problem.

That’s really the issue. “Computational design” sounds fancy, but it’s actually too vague. People either don’t understand it, or they box it into a narrow category often labelled as “fancy magic”.

And because of that, they either ignore it or they reject it. Either way, they leave value on the table by not asking.

As much as I love to do Grasshopper work, I love solving these seemingly small problems with computers more. It’s why I learned to code. And it’s why I believe in understanding the full context of things before solving.

It sounds small but that executable I made saved 6-10 clicks for every VPN toggle. Between going for meetings and working from home, Adam toggled it maybe 10 times a day. That’s 50-60 clicks a day. Over 250 working days, that’s around 12,500 clicks a year. Just for a VPN.

Now multiply that across the whole company and you get an insane amount of time spent on just turning on/off a VPN. And that’s just one friction that I happened to stumble across while on a call.

A lot of the time, people don’t report these problems because they’ve normalized them. We think that’s just the way it works, but really software is meant to make our life easier, not harder.

My work is not just Grasshopper

The VPN executable took me less than 4 hours to build. It saved the average person at Adam’s company about 20 minutes a day. Which is a lot of time and annoyance saved for everyone. I know I’ve said time saved isn’t the only important metric but if you do the math here. It’s 20 minutes x 10 people x 260 working days = 52,000 minutes or 867 hours saved per year.

That’s really the value of digital solutions here. If a problem follows rules, has patterns, or is repetitive, it’s probably solvable with code. I have built things like :

• A tool that saves a user clicks by helping to toggle the VPN

• A tool that helps you exchange contacts more seamlessly, without the hassle of typing in numbers

• A tool that helps you jump to all your folders in your network drive

• A tool that helps you archive and file emails

These are all “small” problems but they deliver immediate value because they directly remove the pain from someone’s everyday work. And when you compound all those savings, it leaves you with more room to focus on the stuff that actually matters.

My value (which I often think about a lot) is not just Grasshopper or even programming. It’s developing solutions for problems like these using digital tools. It’s to bring the “expertise” of programming to these problems that people don’t know can be solved.

Solutions Developer

After working with a few clients like Adam, I’ve started to notice a pattern in why people don’t bring me these problems:

1. They don’t know it’s possible : “I thought you just did Grasshopper”

2. They’ve normalised the friction : “That’s just how the software works”

3. It seems too small : “It’s only 5 clicks, not worth bothering you”

4. The title doesn’t help : If I call myself a “computational designer,” they think geometry only

So, I’m moving away from “computational designer” and calling myself a “solutions developer.”

The title has become too vague and it’s been diluted across so many different roles and quality levels that it doesn’t communicate the scope of what I actually do anymore.

Also, description wise, I prefer “solutions developer” because it is developing solutions to problems for people instead of “computational designer” which sounds like computationally designing things.

But whether I call myself a “solutions developer” or a “computational designer,” it doesn’t change the difficulty of telling people what I do. The title helps, but what really changes things is showing people what is possible to solve.

What I’d ask you to think about

That modelling package with Adam went well, and he’s been a repeat client ever since. The work I’ve gotten from him has ranged from regular modelling to creating plugins and standalone programs for his entire company. All because of a VPN toggle he didn’t know could be fixed.

If you’re reading this and something jumped out at you, reach out to either me or a someone “digital” you know. Maybe you got a process at work that’s always been annoying but you assumed was just “how it is”. Maybe it’s the stuff you’ve stopped complaining about because it feels too small to fix.

Just reach out, because like Adam, you never know, it could be solvable and we could be changing the way you work.

Even if we end up just talking, the conversation is free and at least you’ll walk away with some direction on how to see things differently.

If it’s systematic, it’s solvable.

I’m looking at a folder with four Rhino files and six Grasshopper files. I have “ProcessStructuralGrid.gh” open but which Rhino file does it need? Was it ProjectA_Grid.3dm or ProjectA_Structure_v3.3dm?

I too like to gamble.

So, I chose ProjectA_Structure_v3.3dm.

Well

I chose.......

poorly.

It’s a sea of red components. And if you’ve worked with Grasshopper before, you’ll know that no one ever remembers which Rhino file was used.

The Counterintuitive Part

Most software we use follows a simple rule, one program equals one file. Open Word, you get a .docx. Open Revit, you get a .rvt. The file is the project. Or if it isn’t, a program like Revit at least gives you “links” that tell you what other files are associated to the main file.

But Rhino and Grasshopper don’t work that way. Neither does Revit and Dynamo. You’ll have at least two file types to manage for a single workflow. With RhinoInside.Revit, you’ll have at least three. One Revit. One Rhino and one Grasshopper file for a single project. They’re separate things, but they need each other.

And that’s just one Rhino file, wait until you work with Rhino worksessions.

None of this sounds like a big deal because when we are working on the workflow, we intuitively remember all the files we are working with. But give yourself three months and I promise that you’ll forget. (or maybe that’s just me)

Also, what happens if someone has to open your script ? How will they know which Rhino file it uses. Well, I guess they just have to play Rhino roulette and hope they get lucky.

The Solution

So, I made a free plugin called Recall Rhino. It’s very simple, it basically saves the path to the Rhino file / worksession you had open into your Grasshopper file.

It means, you have one button to save the file and one button to re-open the file.

I’m pretty sure I am not the first to make this but I made the plugin with only this component. It means you won’t get a whole toolbar of other stuff.

That’s it. No more guessing which Rhino file belongs to which Grasshopper file.

I thought of making one that remembers the Revit file too. But we always open the Revit file first before the Grasshopper file. So I’m still thinking of a way to solve that problem.

Final thoughts

This isn’t some next level hack but it does solve a very annoying pain that I have. And I hope it will save you the same pain too.

And if you’re working in a team, or if you’re building definitions that other people need to use, this small component is quite valuable.

Last Tuesday morning was packed.

I was modelling some facade elements in Rhino for a client when I got a message from another client. The plugin that I made for them had a bug. Something about the output geometry not matching their new inputs.

I knew that if I switch to the other task, this facade model wouldn’t get done. So, I took my time to finish it first before switching over to debug the tool. Thankfully, it wasn’t a hard issue, so I put in the fix, ran a quick test and gave it back. I told them that I would run it through more vigorous testing later.

And.... just like that, it was 3pm.

My day started at 7am and I haven’t had lunch yet. So, that was the next thing I did.

The break did me good, because I was roaring to finish off my work for today. But what was work ?

Well, let me check my inbox to see any new emails.

No new emails.

Oh right, I replied to them all. Let me check my task list.

No outstanding tasks.

Right, I did all of them too.

So then, what do I do now ?

Maybe I should refactor that section of the codebase that’s been bugging me. I pulled the latest code down and started looking through it. I was about to start but is this really the best use of my time? The code works. I know it’s not tidy but it works and no one is asking me to clean it up.

Okay, maybe I should write a few outreach messages instead. So, I open LinkedIn and start scrolling through connections, trying to figure out who to reach out to. But I had already messaged a few people yesterday. Haven’t I already done my quota of reaching out for the week? I know I can do more but is that really the best use of my time?

Alright, I could finally clean up that old Grasshopper script I keep saying I’ll get to. So, I open the file, but same as before, is this really the best use of my time?

The next two hours were more of the same thing. I couldn’t stick to a single task. All I did was open tabs and programs until computer complained about it’s memory. Eventually, like my computer, I got so tired of deciding that I closed everything and went for a walk.

The need to be productive

I wonder if others grew up in their careers always needing to prove themselves. And then once they did, that habit (previously good, now bad) just stuck with them. Like there’s this constant need to ensure we are valuable.

I was anxious because I wasn’t doing anything productive. So I kept pulling at straws finding for some way to feel productive. I kept trying new tasks but none of it felt important because I was trying to decide and execute at the same time.

Really, what I should have done is allowed myself to take a longer break, since I worked at 150% in the morning.

It’s strange. I have read enough books to know that I need good sleep. That I need to go to the gym or eat healthily. But when it comes to taking a break from work, I don’t find myself listening to the literature at all. I have this tendency to want to be productive all the time. But much like Icarus, if I keep working like that I’ll burn out.

The need to always want to be productive or as they call it, “high agency” serves me well. It’s this drive to deliver things and provide value for other people. But when it’s the excuse I use to deny myself a break, that’s when it works against me.

I think a lot of people in digital roles feel this. The role doesn’t have built-in proof of value. An engineer has drawings going out the door. A project manager has deadlines being tracked. But ourwork is often hard to measure.

So we fill it with things that makes us seem productive. Right, we “improve” things. We refactor. Worst of all, we build things no one asks us for. We cling to this idea that we have to be building things all the time because it’s our value.

But when the work is done. We shouldn’t try to force new things just because we feel insecure about our value. I’d delivered everything and more that morning. I should have taken the afternoon off, it was a natural gap between projects. But instead, I forced it into something productive and wasted two hours performing productivity because I felt guilty about being finished.

This is the hardest thing when you transition from a role where you’re paid hourly to where you’re paid for the value. Not every hour is equal and not every hour needs to justify itself. The value you created that morning doesn’t disappear because you went for a walk at 2pm.

Sometimes it’s just more productive to rest and not try to squeeze productivity in for the sake of it.

Last week I showed you the problem I had.

Using Grasshopper to check 5,000 elements against 5,000 elements takes a long time. Even for Grasshopper.

My solution as I’ve hinted, is to use a data structure known as an RTree to speed this search up.

Let me show you how this actually works.

What is an RTree ?

The core idea behind an RTree is quite simple.

Instead of measuring the distance from every point to every other point, Grasshopper first builds a spatial index of the points. That index divides space into a hierarchy of locations.

When you query for the closest point, it rules out entire regions instantly and only does the precise distance calculation on the small set of candidates that are actually nearby.

The result turns a four hour search operation into seconds.

Instead of checking every point, an RTree allows the computer to eliminate hundreds of points immediately. This is the reason it drastically speeds up the operation.

Okay, so theoretically, this makes sense but how do we set this up ?

Setting it up in Grasshopper

The plugin doing all the work here is LunchBox.

In it, it gives you a few components that creates an RTree and does the RTree searching.

All you have to do is feed in a list of search points to build the RTree.

Then use the RTree Closest Point component to search for the points within the RTree.

It's that simple. It doesn't seem like much with few points, but you'll notice the difference, the more points you feed in.

At 5000 points, an RTree search took 11ms while the regular closest point took 1.1s. That’s a 10x improvement with not much change to the script.

When I first saw this, it blew my mind.

Using an RTree to pair members

Okay, but what if you have curves and not points? Like my problem, I had 5,000 curves, not 5,000 points.

Well, if you have curves and want to make use of the speed of an RTree search, all you have to do is to find a point that best represents your curve.

This means, you can use the mid-point (or if you’re good with data structures, a list of points) that represent your curve. In my case, because things were mostly orthogonal using the mid-point was good enough.

Instead of a curve to curve search. It became a midpoint to midpoint search. And using RTrees made this operation very quick.

Using an RTree to find points within a distance

You can also use RTrees to find the closest points for a given distance. Especially if you know that you’ll have many results to whatever it is you’re searching.

Read more

The brief said “develop and enhance” their productivity tools in AutoCAD.

They had some tools developed by different people over the years and were maintaining them in-house. But they didn’t have the expertise to extend them, which is why they got me in.

In the first meeting, we started discussing what I could actually help with. Things to fix, things to improve. I mean “develop and enhance” doesn’t tell me much at all. I needed to understand what was actually hurting them.

They told me that they actually have a system to track bugs and features from their users.

I was like wow. Most companies don’t actually invest in something like this.

So, Aiden (not his real name) started sharing his screen.

Honestly, I don’t know what I was expecting.

Subscribe now

It was a spreadsheet.

Their “system” was a spreadsheet.

I shook off my initial shock and started asking some questions. What were the most critical problems right now ? Are there any common features that are highly requested ? Are they looking for a complete overhaul?

And try as Aiden did, he couldn’t use the spreadsheet to answer the questions. We spent the rest of the meeting trying to find the next few things to implement in the tool. The spreadsheet was so complicated and messy that it was hard to figure out which items were critical without reading through all of them. They just knew they needed the tool to be “better”. We eventually ran out of time but I at least understood more of their problem. hint: it’s not the tool itself

So, I had another call with Aiden later and he told me the story of that “system”.

It started out with good intentions. The tool had scaled to the entire company and management wanted a better way to track bugs and features. That’s a good reason. But instead of picking one out of the twenty bug-tracking tools that already exist, they spent 3 months in meetings deciding on how to do it. And it’s still ongoing.

They’re debating programs and workflows. They brought in their legal team to create a new policy. They wanted the quality committee, the technical committee, the directors, you know, the people who don’t have time, to all approve the new system before anything could move forward.

Meanwhile, Aiden still needed a way to track the bugs and features. So, he spent his nights and whatever free time he had building and maintaining that Excel sheet. Manually logging every feature request and bug that came through him.

It became clear that before we could even work on the tool, we needed to fix this “system” first. There was a lot of useful information buried in it, but extracting and managing it was painful.

So, I sent in a variation to the client, suggesting that we work on the infrastructure that supports the tool first, before we go in to fixing the tool itself.

And to my surprise, they accepted it. Maybe Aiden did some “persuasion” on his side.

The tool wasn’t actually the problem

When it comes to digital tools, there’s a misconception that only the tool matters. But the infrastructure around it is equally important. No amount of clean code or better architecture can fix a broken infrastructure.

Deployment. Bug/feature tracking. Usage tracking. Data safety. Change management. These are all things that need to exist to support the tool itself. And most of them were missing or held together by Aiden’s spreadsheet.

Yes, the client needed someone to make the tool better. But they also needed help clarifying what to fix and what to build next. They needed a better overall system. And the work doesn’t stop just because you can’t decide on one.

Indecision is how homebrew gets created

There’s a bias towards meetings and “planning” for new processes which is especially pertinent in larger organizations. And I think, in reality, it’s because no one wants to take responsibility. If I can hold a meeting with every important person and get them to sign off on it, I’ll be absolved of blame if something goes wrong.

I get that. But adding more people to the decision pool just makes decisions take longer. There’s a reason that the saying “too many chefs in the kitchen” exist. At some point, involving too many people will hurt the process.

And while you debate, people start to homebrew things because the work doesn’t stop.

I’ve seen it many times. Engineers making their own tools with AI because the company can’t decide on a program. Drafters using their personal computers to learn how to code because the company wants to roll out a “training program”, but it’s been “work in progress” for 7 months now.

Bug and feature tracking is not a novel problem. You’re not asking for something cutting edge. There are plenty of tools that do this out of the box. The biggest challenge was getting everyone to decide on something.

What I look for now

I used to go into client engagements focused entirely on the technical work. After all, that’s what I’m hired to do. Build the tool, increase their efficiency.

But now, instead of just looking at the tool, I keep an eye out of systemic issues like these.

Sometimes, even though the tool is the pain point, a broken tool is actually a symptom of a bigger systemic problem. And if it makes sense for me to help with that, I will.

In the absence of anything better, the Excel tracker worked. But it was fragile, and it only scaled as far as Aiden’s patience did.

The decision to build a proper system was always going to get made. The only question was when and who would pay the cost in the meantime. It’s almost always the people who actually have to use the system.