Tomra 5C

In 2018, I joined TOMRA as a Lead Developer, working on the software for what would become one of their flagship food sorting machines — later publicly known as the TOMRA 5C.

While the technical challenges were significant, the deeper work was not purely about software. It was about helping a capable team move through complexity, uncertainty, and pressure — and begin delivering with confidence again.

As with much of my work, confidentiality limits what can be said about implementation details. What follows focuses instead on the shape of the problem and how the work unfolded.

The Context: Serious Software in Serious Conditions

TOMRA builds machines that operate at the intersection of physics, optics, mechanics, and software. These are industrial systems deployed globally, often in remote environments, where downtime is costly and support is not a phone call away.

In food processing, their machines sit directly on production lines, making thousands of decisions per second. The output affects food safety, yield, and brand trust. A useful reference point is that every McDonald’s french fry is processed through TOMRA sorting technology before it reaches a restaurant — a testament to the level of quality and reliability expected.

The software underpinning these machines is therefore not an accessory. It is integral to how the machine behaves, how it is configured, and how it evolves over time.

Where the Team Was

When I joined, the team was strong and deeply knowledgeable, with many developers coming from a C++ background. The challenge was not technical competence, but how to move forward.

The system had grown over years, shaped by real customer needs, hardware constraints, and organisational history. There was a strong desire to learn from that history and do things better — but also a real fear of getting it wrong.

That fear was understandable. The stakes were high. The visibility was high. The budget was significant. And the system being worked on would live alongside physical machinery for many years.

The result was a familiar pattern: careful thinking, extensive research, and not enough momentum.

Creating Movement Without Recklessness

A large part of my role was helping the team break out of analysis paralysis without abandoning rigour.

Rather than attempting to design everything upfront, we focused on short feedback loops: building small, representative slices of functionality, pairing closely, and using working software to test assumptions. This allowed the team to replace abstract debate with concrete learning.

On the technical side, the work involved designing and developing the UI layer using C#.NET, WPF, and a reactive programming model, with an emphasis on clarity, separation of concerns, and long-term maintainability. Domain-Driven Design principles helped structure the system around real concepts rather than incidental implementation details.

Just as importantly, we introduced and reinforced XP practices — pair programming, mob sessions, and Test-Driven Development — not as dogma, but as practical tools for improving communication, design quality, and shared understanding.

Growing Capability

Because many of the developers had a C++ background, a significant part of the engagement involved mentoring: helping the team become fluent in C#.NET idioms, SOLID principles, and modern testing practices.

This wasn’t about retraining for its own sake. It was about giving the team tools that made the work feel safer: safer to change, safer to refactor, safer to experiment.

We also worked deliberately on the human side of delivery. Fear of failure was openly acknowledged and addressed through simple, practical measures: shorter iterations, visible progress, and frequent demonstrations that made learning explicit and shared.

Alongside this internal growth, I assisted with interviews, helping the team hire three additional developers to support the next phase of delivery.

Delivery in the Real World

One moment crystallised what this work really meant.

A critical delivery milestone coincided with a physical constraint: a narrow window during which the machine itself had to be moved into place — through a doorway created by temporarily knocking down part of a factory wall, in a remote location, during an off-season shutdown.

The software needed to be ready. The machine needed to be installed. The window could not slip.

The deadline was met.

It was a reminder that in industrial environments, delivery is not abstract. It is tied to cranes, factory floors, and real logistics. Software either shows up when needed, or it becomes the problem.

Reflection

Looking back, the success of this engagement had less to do with any single technical decision and more to do with creating the conditions for good decisions to be made repeatedly.

That meant:

• shortening feedback loops
• making uncertainty discussable
• grounding conversations in working software
• and helping a team trust itself again

As one colleague later put it:

Nathan was instrumental in breaking analysis paralysis… helping shift from a deadline-driven mindset towards an end-user, value-generating one, and embracing an agile-done-right approach.

That description captures the spirit of the work well. The goal was never to impose a methodology or demonstrate expertise for its own sake. It was to help a capable team move forward with clarity, confidence, and momentum — and to let the software emerge from that foundation.

It’s a pattern I’ve seen repeatedly in high-stakes environments. And it’s one I’m always glad to help with.

Also on the Nhance blog: Delivering the TOMRA 5C and Salvation on a trolley.

Technologies Used