Bridging the hardware-software gap

Nico Meijerman joined NTS to help build and expand the company’s software competency. Shortly after arriving at the hardware stronghold, he started to work on bridging the gap between software engineering and the worlds of physics, mechanics and hardware-related disciplines. The result is a workshop in which Meijerman teaches his non-software colleagues the basics of software engineering. Customer and business specifics included.

First-tier supplier NTS Group has quietly been shaping its software engineering competence over the last couple of years. You might not expect this from a company that’s still making most of its money by bending sheet steel, milling parts and assembling systems.

However, embracing software expertise is a natural step for some first-tier suppliers. Over the past decades, NTS has been actively building its system development capabilities. It now develops and manufactures complete machines and modules that are branded and marketed by its customers. With the value of end products shifting to software, it seems a natural move for NTS to develop the competences to catch the digitization wave.

NTS’ Development and Engineering (D&E) department has a headcount of about two hundred engineers, of which 15 percent focus on software. For a supplier that delivers high-end systems and designs, this is still on the low side, Meijerman argues. “It will grow because we see software becoming more and more essential for creating value for our customers. We see the software effort increasing in our projects.”

“We see the software effort increasing in our projects”, says Nico Meijerman. 

An intriguing offer

Meijerman has been walking the hardware-software trail for his entire career. He learned to design chips during his study in Twente and joined Sagantec, a company that both worked on a silicon compiler and developed application-specific ICs for customers. There, he started designing chips, but soon enough, he shifted to programming because the embedded software turned out to take more effort than the hardware itself.

Later, Meijerman taught informatics-related subjects at several departments of the university of applied sciences (HTS) in Arnhem. Subsequently, he joined Philips CFT, where they needed a software engineer who understood what was happening in the mechanical and electrical domains. There, he developed motion control software for ASML’s first PAS 5500 litho scanners. Soon after, he also worked on MRI scanners for Philips Healthcare.

In 2010, Meijerman decided it was time to start his own consultancy company but a few years later, NTS approached him with an intriguing offer: would he be interested in becoming the group leader for machine control, a team focusing on software and electrical engineering. Helping to build up the software competency seemed a daunting, yet very attractive challenge.

After arriving at the hardware stronghold, Meijerman knew he needed to work on his relationship with the NTS mechanics and mechatronics base. He figured a short workshop would help make his new colleagues more familiar with software.

According to Nico Meijerman of NTS, “Mechanical engineers deal with the limitations of physics, software manages complexity.”

Meijerman started interviewing colleagues to get an idea of their needs. First, he talked to the systems engineers – the guys that mostly have a mechanical background. “The most frequent response was that they had no clue about software. I heard remarks like ‘Those guys are always too late’, ‘They never make the things that I really need’ and ‘I can’t work with them because they don’t understand anything’. It was very much a culture of blaming and it was clear that our systems engineers didn’t know what software was doing. They saw it as an unpredictable black box.”

In Meijerman’s contact with the system architects, things started to resonate more. “They at least got an idea about what they would like to know about software. They wanted to know more about programming languages, third-party, multi-tasking, real-time, Agile and other basic concepts. They also wanted to know what a software development process looked like.”

Before long, Meijerman and the system architects concluded that the customer perspective is of enormous importance. “We saw the need to involve clients early in the software development process. For NTS, this was a high priority because most of its customers have a mechanics background. They know that software has to be included but they have to be educated on the specifics – for instance, on the fact that software is never bug-free. That’s why part of my workshop is also about business models and everything that follows our development activities.”

Nico Meijerman is the trainer for ‘Software engineering for non-software engineers’. 

Wrong assumptions

In the high tech industry, you often hear that communication is the problem in settings with different disciplines. But at NTS, Meijerman experienced that it’s more about understanding and being able to step in someone else’s shoes. “People do try to communicate. I see that there’s definitely a willingness to talk,” he says. “But hardware and software engineers are often living in completely different worlds.”

Meijerman explains that mechanical engineers predominantly look at the limitations of physics. “It’s about nanometers, about milliseconds. The stiffness of a construction determines what you can achieve. Components wear out if you use them too long.” Software engineers, on the other hand, do not deal with physics; they try to control complexity. “Mechanics is about managing the limits of physics, while software is about managing complexity.”

The problems often arise from wrong assumptions. “Mechanics rarely ask a software engineer about the degree of complexity. That’s why a software engineer will say in most cases he can fix a machine control problem – except for some very difficult issues. But if you ask them how much effort it’s going to take and how complex it is, you may get a completely different answer. A mechanical engineer looks at things from a physics point of view, not from a complexity point of view. But he should know how much work his question can generate. The lack of understanding of such basic concepts makes it difficult to interact. Equally, software engineers definitely have to improve their knowledge in the field of mechanical engineering.”

Part of Meijerman’s workshop is understanding that software engineering isn’t the same as programming. “Youngsters are learning how to program while at university or during technical education. A lot of people think software engineering is just more programming but that couldn’t be further from the truth. In programming, complexity usually isn’t the issue, as you’ll end up with some hundreds of lines of code. It’s not until you’re dealing with over a hundred thousand lines of code that it starts to get complicated. In high-tech systems this is the case: there are sometimes millions of lines of code, and the only way to tackle challenges of this magnitude is to find a way to work through the problem. That means breaking it down and ensuring that your work is correct. Engineering is about focusing on architecture and design, as well as managing complexity.”

“My goal is to teach participants all aspects of software engineering,” Meijerman concludes. “When they realize that, they understand that they can’t ask their nephew playing with Arduino boards to write a program for them over the weekend.” At the end of the workshop, participants understand more about the intriguing world of software engineering and about the differences and commonalities between software engineering and other disciplines, resulting in better collaboration, better solutions and hopefully more fun in their work.

This article is written by René Raaijmakers, tech editor of Bits&Chips.