A client once asked me to review an automation they had been using for years. They were an engineering manufacturer with several product lines, but the automation had only been built around one of them.
It was old but still really good. An engineer could configure the product in a spreadsheet and, with a push of a button, get a 3D model, a list of materials and a detailed set of drawings ready for production. They still had to clean up the drawings and add any custom parts, but the tool removed a huge amount of manual work.
Now, they wanted that same kind of efficiency for another product line.
The obvious starting point was to repurpose the tool they already had. But the tool had grown around the first product over several years. Its code, templates and rules all carried decisions made for that particular product. The client suspected that adapting the whole application would be expensive and bring across features the new product did not need. They still needed to know whether any of it could be carried across.
I was brought in to move the automation across. Given its history and complexity, I suggested we begin with a discovery phase. I could not assess a tool that had been working for several years from a surface-level explanation.
I discussed the existing and proposed workflows with the client and inspected the current tool’s code. Because I was coming to it fresh, I could stop and question decisions that had become a normal part of the workflow. I looked at which rules belonged to the underlying engineering process and which parts had grown around the first product line.
We spent close to a week in meetings and reviewed the codebase against sample files. The findings were close to what the client suspected. The current automation depended heavily on templates, parameters and files that were specific to one product line. Carrying all of that into the new product line would add functionality the workflow did not need and make the new application harder to maintain.
Rebuilding everything from scratch would also waste useful core engineering code. The application itself was the wrong starting point, but the codebase already had the company’s standards and rules baked in. Those parts were worth reusing.
My final recommendation was to keep the existing automation where it was and build a new one around the second product line, reusing only the engineering logic that genuinely belonged to both. That would preserve what already worked while giving the second product line a tool designed around its own workflow.
The client’s hunch was right, but the discovery phase still mattered because it turned that hunch into a clear direction.
Hi, I’m Braden
I help teams be more efficient in the AEC Industry, then share stories about it here. I also have courses, guides and scripts as part of CodedShapes Pro
Check it out if that sounds like you.
If you’re new to CodedShapes, welcome! You might enjoy these:
Got a workflow in mind ? Let’s build it together.
A correct hunch still needs a build plan
Clients usually know their own workflows better than I do because they use them every day. They know which parts cause trouble, where people lose time and which tools have become difficult to work around.
A reasonable suspicion and a goal are enough to begin investigating, but they are a poor basis for defining the scope and price of a build. Suspecting that the existing tool would be too expensive to adapt told us nothing about what to do next. If it was too expensive, what should they do instead?
So, we needed to find out whether the expense came from the code, the rules, the templates or the way the tool had grown over time. Maybe the hunch was wrong and replacing a template would have been enough to keep it working for the new product line.
The discovery gave us the evidence we needed to explain the hunch. We could show why adapting the whole application would be expensive, which parts were still worth reusing and what the next steps should look like.
The investigation should match the uncertainty
Not everything requires such a detailed discovery phase. A small script and an established application carry different risks, so they do not need the same investigation.
The time and effort needed to reach an answer scale with the uncertainty. We still need to understand the pain points and the workflow, whether we are building a script or a full application.
Before I scope the build, I might ask for sample files, process documents, the codebase or the tool itself. That material gives us something concrete to investigate and a basis for deciding what comes next.
But we cannot stay in discovery forever. At some point, more investigation stops removing meaningful uncertainty and only delays the build. I tend to match the investigation to the consequences of the unknowns. If we cannot explain how it should work, what the inputs and outputs are or which assumptions could change the scope, then we still need to investigate more.
Sometimes a call and a few sample files are all it takes. In a case like this one, it can mean working through the manual process, the current problems and the existing code.
In the end, the client did not get a surprising answer. Their hunch was correct, but it was now supported by evidence and they have a clear direction on how to move forward. They knew what to leave untouched and what could be reused.
So if something is complex and you have a hunch about it. You should test it before making any decisions. This sounds like common sense but in this AI era, it can be so easy to over build something because it seemed easier.
The whole point of this is to understand what is going on and how to move forward.
Thanks for reading
Subscribe to CodedShapes to get more articles like this delivered to your inbox
Work with me: https://codedconstructs.com/contact/
Resources on Computational Design: https://www.codedshapes.com/p/scripository