Why We Treat Software as Core Engineering

Back to Library

Issue #18323 - June 2026 | Page #29
By Brett Kinny

Frame and truss machinery has always competed on mechanical engineering design, and it still does. But, when you ask a plant manager where the day-to-day pain and gains in their plant actually come from, increasingly the answer is software. Throughput, uptime, operator experience — these now depend on code as much as steel. The buyers who have noticed this are starting to ask different questions about what they’re buying, and they’re not always getting good answers. Many vendors are still selling machinery built on old-generation technology and user interfaces that look 20 years out of date.

Bringing Software and Automation Together

At Spida Machinery, we’ve built our Automation Software team around the idea that software deserves to be treated as core engineering, not as something bolted onto machines as an afterthought. That shapes the people we hire, how we ship releases, and how we support our customers across Australia, New Zealand, and North America.

Most teams keep automation and software separate, but not us. We have automation engineers and software engineers — and all are domain experts on the machines, with deep overlap between the two roles. They move between the disciplines fluently, bringing software practice into automation and automation rigor into software.

That overlap is where the leverage is, and the wider automation industry is only now starting to catch up to it. We have been working this way for years. [For all images, See PDF or View in Full Issue.]

Why Continuity Matters

Several of our engineers have been at Spida for 10 years or more. Several others have passed the five-year mark. That continuity matters in a way that doesn’t always show up in a brochure. When you call us about something odd happening in your system, the team handling it has likely been working on that system, or one like it, for the better part of a decade. Diagnoses come faster, updates introduce fewer bugs, feature decisions are smarter. Our engineers have spent time on the factory floor, and they understand the needs of the machine operators.

The Foundation for Better Software

Our automation and software are built to ISO 13849 and AS/NZS 4024 from the design stage: our lead engineers all have formal training in functional safety. We run strict QA and have a dedicated software tester on the team. Releases go out on a regular cycle, and when something needs a hotfix, the team is structured to push one out in days rather than months. This is the foundation everything else rests on. Above it sits our R&D work, where we get to do our most interesting engineering, and where we test what we believe about how our software should be built.

Take the GlideAway, our flagship truss assembly system, which combines automated jigging with robotic handling of nail plates, picked and pressed accurately at the joint without operator intervention. We have three of these systems in the wild, and the engineering on the platform has not stopped. Each release tightens accuracy, trims cycle time, or shifts work the operator used to do onto the machine. The system gets easier to run, and the throughput keeps climbing.

Keeping Support Close to the Install

All of this depends on being where our customers are. We support our software across three countries and multiple time zones. When a plant calls, our local service team picks up, not a queue on the other side of the world waiting for a different shift to come in. When something needs escalating to the software team, the software team is in your region too. The whole chain stays close to the install. Problems land with people who can act on them today, not someone reading a ticket days later.

Building for What Comes Next

We watch what other industries are doing and bring back what fits. Customers are asking for deeper data integration, the kind of insight that shows what is actually happening on the plant floor in real time, not just what got produced at the end of the shift. They are asking for predictive maintenance, so that downtime gets planned rather than discovered. They are asking for machines that are safer and more efficient at the same time, which is a harder engineering problem than either one alone. We have been building toward this for years. The discipline, the team, and the in-region footprint are what let us keep building.

The Software Partnership Behind the Machine

A frame and truss plant chooses machinery for the next 15 or 20 years. That decision is also the choice of a software partner for the same period. We think the choice should be made deliberately.

We have built our team so that when our software is running in your plant, the people who write the software will continue to support it, and keep making it better with every release.

If any of this resonates with you, we’d be happy to continue this conversation.

Brett Kinny

Author: Brett Kinny

Machinery Software Manager, Spida

You're reading an article from the June 2026 issue.

External links

Search By Keyword

Issues

Book icon Read Our Current Issue

Download Current Issue PDF