Why It’s Important to Understand Before Solving
How I built a tool that no one wanted to use
It was a slow day and I was in the office working on a reply email for a client. Sav, an engineer at the company whom I know well, came to my desk with a classic automation opportunity. He asked me if there was a quicker and better way to transfer post-tension (PT for short) data from his design software (RAM Concept) into the programs used to create engineering drawings (programs like Revit).
The main problem here is the program that engineers use to design the PT and the program that drafters use to document the PT for construction are two separate and very different programs. Which meant that the same data needs to be entered twice manually.
Their current workflow was painfully manual. Engineers would design their PT in RAM Concept, generate detailed PDFs showing the tendon layouts, then hand these over to the drafters. The drafters then take these PDFs and meticulously place each element in Revit then produce the construction level drawings for the engineer to review. When the engineer reviews, they would circle in red and comment on the drawing itself for the drafters to change in Revit. Once those changes are made in Revit, the engineer has to also make those changes in their RAM model.
I was confident I could make this more efficient, so I agreed to Sav's request. After several planning meetings together, we mapped out an ambitious tool that would read the RAM data, interpret it's geometry, and automatically generate the corresponding Revit elements. I could almost see the excitement in the air as we planned out this tool. "This could change everything," Sav said. No more spending days getting PT into Revit, with this new workflow, we could do it in half a day.
Our estimate was six months of development time and we also got the approval from the directors to make this. So, it was time to start development.
I spent countless late nights solving edge cases and refining the algorithms. When we were ready, we even recruited other engineers to help us understand the nuances of PT design and to test the tool across five different projects. The good news was that everyone we spoke to was genuinely excited about the tool. My work was going to make an impact and it was really going to save countless of hours.
Our test results were promising too. For those five projects, we've successfully transferred the PT data from RAM to Revit and the generated models matched the engineering intent perfectly. Each time, the tool ran, we felt more and more confident about the tool.
The tool was a huge success. So much so that Sav started conducting informal training sessions for both engineers and drafters. The tool became more than just software – it became the standard way that the office would design and document PT. Even the directors were impressed at how much time the new tool saved.
A few months since the release, the directors told us to present the tool to our Melbourne office. Sav and I made impressive slides from all the previous projects and the benefits of the tool. We even labelled "The future of PT documentation" in the slide. We were that confident.
When it came time to present, Sav and I went through the slides flawlessly. It was the proudest we've ever felt because it was a tool with real impact. That was until Jo, the head engineer of the Melbourne office, looked confused and asked "why didn't you just use the direct export to bring the data into Revit, that's what we do here in Melbourne".
That was the first of many. More people joined the rebellion. "Yeah, this just seems like a fancier way to do the same thing". "Did you say you spent a year on this ? Isn't it quicker to just teach engineers how to use RAM better?", "Why didn't you ask any of us ? We could have showed you a quicker way"
It was embarrassing and infuriating. As I pressed "end" on the video call, I just stared blankly at the computer. How did we miss such a crucial feature? When I snapped out of it, I sent Jo a message asking if he could show us what he meant.
My heart sank as Jo pulled up RAM Concept on his computer. With a few clicks, he exported a file in a format I'd never seen before. He then opened Revit, made a few quick adjustments to some settings, and there they were – the PT tendons. It wasn't perfect but it was 70% of the way there. Instead of saving hours, our tool actually only saved minutes. Was bringing the rest of the 30% really worth the time we spent on the tool ?
Sav and I had poured our hearts into this tool, a tool that won the hearts of our office. Even the directors loved it, but it was for the most part unnecessary and costly. It wasn't a complete lost though, we did actually help save a lot manual work and it is still technically better than Jo's way but it was still a painful lesson.
Jo's method became preferable and the new new default way over our tool because no one had to install anything. That also meant that we retired our tool because it was too costly and not worth the effort to maintain.
This experience fundamentally changed how I approach anything new. When someone comes to me with a problem or an idea, my first response isn't to start thinking about the solution – it's to start asking questions. I now spend more time in the discovery phase, talking to different teams, understanding their workflows, and investigating existing solutions before I ever write a line of code. The most valuable skill in computational design isn't code – it's knowing when not to code at all.
Your Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t Stop To Think If They Should
Jeff Goldblum's character Ian Malcolm in the original Jurassic Park film.
In Summary
1. Research Before Solving
The most crucial step in any project isn't writing code – it's understanding what solutions already exist and if a new one is necessary at all. Spend time investigating:
Built-in features of existing software
Workflows used by other offices or teams
Industry standard approaches
User forums and documentation
2. Understand the Operational Context
As computational designers, we often focus on the technical challenge while missing the operational reality. So before you start anything, try to:
Talk to the people actually doing the work
Understand the full workflow, not just the part you're trying to automate
Consider how changes in one part of the process affect others
Remember that perfect automation isn't always better than a good-enough existing solution
Looking Forward
For computational designers, our value isn't just in our ability to create new tools – it's in our ability to identify when tools are actually needed. Sometimes the best automation is no automation at all. Instead of asking "How can we build this?" we should first ask:
What problem are we really solving?
Is this problem already solved in a way we haven't discovered?
Will building something new actually make things better?
The next time you're tempted to dive into development, take a step back. Spend time understanding the problem space. Talk to more people. Research existing solutions. Be comfortable saying "let me look into this first" instead of immediately promising a solution.