I’ve spent most of my career working with engineers on test systems—the kind that look elegant on a block diagram but become brutally complex the moment real hardware, real data, and real timelines are involved. Over time, I’ve learned that the hardest problems in test and measurement are rarely solved by better tools alone. They’re solved by people—engineers learning from one another, challenging assumptions, and sharing what works (and what doesn’t). 

My realization didn’t arrive all at once. I was first introduced to NI LabVIEW in 2007. For the first several years, I focused primarily on writing and commissioning software for test and production systems. Like many engineers, I was heads-down: solving the problem in front of me, optimizing performance, and making systems reliable enough to survive production. Community existed mostly as forums for me. 

Things changed when I founded Hampel Software Engineering GmbH in 2016. 

Leading a group of engineers that integrates with customer teams forces clarity. You quickly see that no single team, vendor, or expert can solve today’s challenges alone. Software-defined test, real-time systems, FPGA acceleration, massive data flows, long-lived codebases—these demand collaboration by design. 

One of the earliest lessons came from working closely with a team at Siemens Energy on high-speed simulation and communication systems built on real-time and FPGA platforms. The technical challenges were significant, but the real differentiator wasn’t clever code. It was the way engineers across organizations openly shared knowledge—from architectural patterns and performance trade-offs to failure modes.

That collaboration laid the foundation for our NI Center of Excellence certification in 2019. What mattered wasn’t just what we built, but how we built it: together, with transparency and trust. That experience has since shaped how we approach every project.

Another example came through our work with HAGE, an Austrian special-machinery company. Together, we developed an NI CompactRIO-based system that evaluates weld seams in real time for tanks used in the Ariane 6 rocket program. This required high-speed NI DAQ, deterministic control, industrial communication, and laser sensing—all operating reliably in production conditions.

Projects like these don’t succeed because one team knows everything. They succeed because engineers are willing to share lessons learned and build on existing knowledge instead of reinventing it.

Perhaps the clearest illustration of this came through our work with ZF Mobility Solutions on an ADAS record-and-replay system used to test electronic control units for autonomous driving. The scale was immense: gigantic data volumes streamed through high-performance PXI systems, replayed into real sensors and ECUs, and then captured again for analysis. 

Managing that level of complexity forces discipline—in architecture, workflows, and collaboration. We worked side by side with the customer and with NI engineers, aligning on frameworks, automation strategies, and long-term maintainability. From beginning to end, it was a benchmark example of how customer, partner, and platform provider can move faster together than they can on their own. 

I’m especially proud that this collaboration helped ZF Mobility Solutions pass its Center of Excellence audit in under two years. That outcome wasn’t accidental. It was the result of shared responsibility and open technical dialogue.

Over time, these experiences pushed us to invest heavily in open-source projects and shared tooling. We became known in the community for our work in workflow and process automation (CI/CD) and eventually productized parts of that work. We also built and maintain a public wiki that has become a trusted resource for engineers working with  LabVIEW and modern software practices. 

We do this for a simple reason: engineering improves when knowledge is shared. Open source isn’t just about code. It’s about ideas, feedback, and collective problem-solving. By sharing how we work, potential customers get a clear, honest view into our approach. And for teams starting from scratch, our freely available, proven workflows and tools give them a strong foundation. When those teams eventually need scale, confidence, or support, they already know who to turn to.

Advancing test and measurement requires sustained investment in the community itself. That means supporting user groups, conferences, open-source initiatives, and education—not as side activities, but as a core part of the strategy.  

When we work with NI engineering teams, the relationship goes beyond products or individual projects. We’re helping shape the practices and workflows that thousands of engineers will rely on in the future. 

That belief is reflected in our own involvement in the community. We cofounded GDevCon, where I now serve as chair of the board, and we actively run user groups like WUELUG and NOBLUG. These events may look informal from the outside, but their impact is very real. They are places where problems are discussed openly, patterns emerge organically, and engineers leave better equipped than when they arrived. 

The same is true for open-source projects, shared documentation, and online collaboration spaces. Together, they form an often invisible infrastructure that supports innovation just as much as any hardware platform or software release, creating continuity between generations of engineers, between academia and industry, and between individual projects and long-term ecosystems.  

If there’s one lesson I’ve learned, it’s that strong engineering communities don’t emerge by accident. NI teams have understood this for decades and continue to act on it. The result is a community built on shared experience, mutual trust, and engineers helping engineers solve real problems. 

As test systems become increasingly software-driven and interconnected, the role of community will only become more critical, and this is a positive development. But collaboration at scale doesn’t work without solid foundations. Professional software engineering workflows, tooling, and shared practices are what make collaboration sustainable, repeatable, and effective. This is an area Hampel Software Engineering has been working on relentlessly for over a decade, and it’s encouraging to see NI teams place strong, visible support for these workflows at the top of their toolchain priorities. 

Progress does not come from tools alone, and it certainly doesn’t come from working in isolation. It comes from engineers who combine strong technical foundations with the ability to collaborate, share knowledge, and build on one another’s work. Modern tooling and workflows don’t replace community—they enable it. 

That’s why, when we talk about the future of test and measurement, the focus shouldn’t stop at platforms or performance metrics. It has to include people, practices, and the workflows that connect them. I’m optimistic about where this is heading: strong communities, supported by professional engineering practices, are becoming the norm rather than the exception. That belief strongly shapes how we work at Hampel Software Engineering—because when collaboration is intentional and well supported, progress follows naturally.