Why Bridge Building in Engineering?

We need to break down our silos to survive in the world of software-defined vehicles

Why ‘Bridge Building in Engineering’? I realise every day that the people who work in development at my company can be divided into two categories: either they are like Harry Hardware, or they are like Siggi Software.

Harry and Siggi work for the same company, are sometimes in the same teams, and yet they are often completely different in their thought patterns and language. Mentally, they live on different islands.

Harry Hardware and Siggi Software use different languages

The fact that the two live on different islands is most easily recognised by their language. For example, when it comes to defining what a system that is being developed is, Harry describes it like this:

"I develop my system, define every aspect of it, need precision and independance and release it when it's 100% correct."

If we now ask Siggi the same question, we will get the following answer:

"I develop my system, need a global understanding of the requirements, seek precision for at least the next iteration, seek to reuse as much as I can and release it when it is ready to use and expect feedback for the next cycle."

Here you can already see the fundamental difference in the approach: Harry tries to be as independent as possible from other systems. He has his installation space and his defined interfaces, which is sufficient. He wants to have as much control as possible over every aspect of his part or system component. He also needs the time until he can deliver something, because for him there is only one deadline: as soon as he has delivered something, production of the component or system begins. If something has to be changed afterwards, it becomes incredibly time-consuming and costly.

Siggi, in contrast, does not have this one very important milestone. Of course, he has to deliver his work results by the delivery date, but there is a crucial difference: a correction and therefore a subsequent delivery is much cheaper and quicker to carry out in software than in hardware. That was also the reason why the software discipline was created in the first place.

Another aspect is that Siggi tries to reuse as much as possible: be it from his own code or from central libraries that are either provided by other departments or come from external frameworks. Open source software plays an important role here. Using this is often more sensible than developing the function yourself.

If you now ask about the guard rails, the basic principles on which Harry and Siggi base their professional ethos, you get the following answer from Harry:

"My holy bible is the DIN standard (German Institute for Standardisation): Do it right the first time"

Siggi answers the same question like this:

"My holy bible is the manifesto for agile software development: cycle often, close late"

Here you can see the fundamental difference in the approach: Harry works towards a target date, after which he is finished. Siggi publishes a version that works on the target date, but continues to develop it afterwards and changes and optimises the solution permanently. With appropriate update mechanisms, the product is constantly improved and optimised in the hands of the customer.

Another quote from the two:

Harry: "After packaging, I have my own build space and can develop until we physically integrate our component with other components."

Siggi: "It doesn't make sense to do everything ourselves. Which parts could we implement in a generic way so that I or someone else can reuse them?"

You can see from these quotes that it's not just about the terms used, it's definitely a mindset issue. People like Harry are so conditioned, they have trained themselves to work this way and often can't help it if they don't understand this new, emerging world of software. It is in the nature of things that a change in hardware has massive economic consequences, and therefore any strategy to minimise risk is fine. In most cases, however, the simplest strategy is chosen: I'd rather do it myself, then I know what's in it.

This is an approach that Siggi Software sometimes also has. But there's a catch: if I do something myself instead of reusing something, then I also have to maintain this source code myself. Software is generally very maintenance-intensive. That's the other side of the coin, and it's also the reason why Siggi Software is always looking for generic solutions that can be reused in different places. One method of choice is abstraction or generalisation. And this is also a key difference: this ability to abstract is usually not available to Harry Hardware or is not actively trained.

We need a common language

We need a common language. You can find out how we can achieve this in the following blog posts.

What experiences and examples do you have of SW and HW people not getting along?

Do you agree that you first have to agree on a common language in order to be able to work together effectively and efficiently?

Please leave a comment or send me a message. Stay tuned for more to come soon!

And don't forget: keep on rocking in a free world!