Why "Made In Germany" ain't a thing in software

authors

Matthias Kainer

Germany is renowned in the world for their quality, their engineering craftsmanship, for their cars. Back in the days, when a car was more than just a transportation tool, a vehicle produced by a german brand promised unmatched “Freude am Fahren” (driving pleasure). With their engines unique. Their quality outstanding. Acceleration, sound, vibrato; those cars were built for race tracks or the German Autobahn. And that aspiration was there even when driving it on your runway.

But the times, they are a-changin'.

With combustion motors, even one series of one model had a lot of various engines. Thus, a manufacturer’s portfolio could offer a few hundred different motors, while with electric vehicles it’s two or three.

Unlike drivers of a traditional vehicle, drivers with electric cars will often play it defensive, even on the Autobahn, to increase their range. The sound of the motor does not reward them. Their motivation comes from an app on their middle screen, congratulating them on their economical driving.

No longer is driving experience driven by mechanical engineering or hardware. But by Software inside the vehicle.

But unlike in traditional engineering, Software “Made in Germany” has not been associated with anything specific. There’s SAP, but their Software is not associated with brand experience or suffusing their customers with delight and happiness.

For the multimedia systems owned by german manufacturers, the same lack of experience holds. And you can observe this issue in a lot of different areas in the German industry.

But why is that? What makes the German industry seemingly unable to deliver to their expectation?

There are multiple reasons, and you might want to argue which one is the most urgent. Some are pressing for more innovation, while others may feel that companies do not have a clear data strategy.

I feel that the reasons are much more profound: The German industry does not take their “Handwerkerehre” to the Software. Many companies are still of the opinion that Software Development is closer to taking dictation from the business than building a product. And all of them are putting their future at risk, as they fail to see that there won’t be a product with apps on top. There will be only a product. Software will be an integrated part of it. And if the Software is terrible, so is the product.

So let’s take a look at the details.

Lack of Handwerkerehre

Whenever a new electrical product gets created, every electrical engineer in Germany adds a circuit breaker first. It’s the right thing to do.

While an apprentice carpenter builds a table, the master will verify the quality, durability and rigour that they expect after every single step. They will check in with their constituent for every significant milestone to make sure they match their expectation. They will take ownership over that table during its lifetime, polishing it and maintaining it, allowing it to last generations.

The first thing many software developers in Germany do is write a few thousand untested code lines and claim that showing those lines of code to somebody else for 5 minutes will make sure it works. A few weeks later, a project manager will put them on the next project.

Compared to the painstakingness other occupations in Germany are putting in their work, the amateurish take on their craft by Software Developers is alarming.

The first thing that has to change is establishing a commitment to quality like the circuit breaker pattern electrical engineers have. And the equivalent of that in software development is automated testing. One might argue formidable on how to test correctly, but this is no excuse to not test at all. As a customer, I expect that every feature in a product is verified to work and will continue to work no matter what. It’s not acceptable that this is not the norm in Software.

Another element that goes into quality is the 4-eyes principle. Or the lack of it. More often than not, one developer will work on a feature alone. It will be embedded in a product that is so complex and complicated that only a computer can compute its overall complexity.

If only a computer can measure the complexity, how can one person claim to understand the impact of their change?

To counter this, code reviews have become somewhat common practice. It boils down to a workflow where the developers will make their code changes available to other developers who are often busy working on entirely different features, asking them to approve their change quickly to continue with their subsequent work. Those reviews’ thoroughness is often lacking, unsurprisingly, and the product’s quality will degrade slowly with every change.

I claim that products have become too complicated to allow a single person to work on them alone. Two developers should pair on writing every line of code, and one of them should ideally be very senior. This practice will increase code quality for multiple reasons. First, it will prevent the pure amount of code from becoming the Ring of Gyges that allows the programmer to hide all shortcuts in. Secondly, when two people work together on the same code, they will talk. They will ask questions, and those questions can uncover hidden complexities, unravel bugs, and create paths to allow for a better and more sustainable architecture. Yes, this requires a safe working environment, and people open to show they don’t know everything. It might look inefficient from the outside when you see two software developers searching for answers on what to do on the internet at the same time. In reality, one person might search even more often, as two people usually know more than one.

And then there is the security or the lack of consideration thereof.

If the company is thinking about security in software development, next to excel sheets and slide decks, they will do some penetration testing for the most significant releases.

Now, even if the product has updates only once a quarter, it is an entirely different version of the code every time. A lot of parts have been refactored or rebuild. Completely new things were added. However, Product Management is not considering it a new big release, so no testing necessary.

It’s the equivalent of not doing crash tests for the VW Golf generations 2-5 because generation 1 had one.

More importantly, in Software, you can do automatic tests for security at meagre costs. And run them for every change a developer adds. Every change will be taken through extensive checks to ensure the code still complies with corporate policies and doesn’t run a high risk of leaking all the valuable data assets the company has collected. However, only very few companies in Germany care enough to add those tests to their products.

All those things are serious, and a lot of people are aware of them. Then why are they not changed?

Software development belongs to the same organisational entity where management put it 60 years ago. The change of importance Software has to the products those companies create was not reflected in the organisational structure.

Wrong Organisational Model

Considering the number of companies whose organisation I had a chance to see, the percentage of companies with a structure that places their Software Developers in a business unit that would allow them to follow the guidelines above is low.

The reason is that the top management perceives software departments as a cost centre. A CTO or CIO is often placed under the CFO, and a CFO has the goal to work on cost efficiency rather than investing money. If your annual goals are on making sure your OPEX is low, there is no reason for you to have enough developers to even allow for pairing.

For companies with a traditional engineering department positioned directly on the board, the situation tends to be even worse. The Software Systems are now often distributed so that the “traditional IT” like CRM is still under old jurisdiction, whereas the Software embedded on the devices is in engineering. Customers, however, are used to getting individualised experiences from Software. As this will require information from the CRM, which is optimised for costs and not to create value, this organisational setup will hinder the product’s success as a whole.

And as a result, this company will have crappy products. And it will fail.

If you are a CEO in Germany, and you are creating a product that has even the slightest bit of Software running on it, and some part of your IT is still optimised for costs and not to create the best product, I say you are personally responsible for every failure of your organisation to deliver great products in the next 25-30 years.

Project Based

And finally, there are projects. Projects resonate with a lot of people in Germany. They require micromanagement; they have a well-defined duration; you can blame others if they overrun. And then you can jump to the next.

Projects, however, are entirely different from the carpenter example above. Or how car manufacturers manage the lifecycle of their models.

Projects, on the other hand, don’t involve any lifecycle management other than minimum operating. More often than not, Software developed as a project does not even have a plan for the end of life.

Yet, there are good reasons why it is the default tool for Software Development in Germany. It follows the constraint we have highlighted above; above all else, it is a tool to make sure you can create any Software in an environment that requires you to act cost-efficient.

To help achieve this goal, companies in Germany often have large clusters of external contractors that deliver one project after the next without focusing on organisational success. The number of internal employees in Software Development is usually low and concentrate on managing roles.

Now, why is that an issue?

Imagine companies would build cars this way. While you as a company are in control of orchestrating the creation of the car, in the end, you will lack knowledge of how a vehicle is built. You have little control over staffing those projects, and possibly you will lose the learnings people made from the first fabrication. Even worse, they might not be as interested in the product’s long-term success because, ultimately, it’s not theirs. They will no longer be there 20 years from now when there is a problem with that thing. Their focus will likely be on different areas, based on what their company has as a priority.

Should you thus stop bringing in external companies at all? Probably not. The external companies might have qualifications that you don’t have in your company yet. You can use this to upskill your people. To shift your culture. To then, for instance, establish the tools I presented in the previous chapter.

However, you must have people in your company on every level that ensure that the things you build are sustainable. People who are aware that 20 years from now, the product they produced is still theirs; otherwise, your product will suffer from the tragedy of the commons, which is probably the last thing you want to explain to your customer.

Following a project-centric approach, you will rarely achieve this.

Therefore, when developing software for your product and thinking to run this as a project, imagine buying it of the shelf instead.

If buying feels wrong for you because that new part is a distinguisher in the market, then create a product.

Just don’t do Projects.

Summary

Software development in Germany in a lot of companies gets treated like one-time marketing expenses. A mobile app is seen as an equivalent to a ball pen with your companies logo on it, and the companies ignore that, unlike the ball pen, Software is part of their product now.

Companies in Germany should consider the following changes to avoid that “Made in Germany” will become the opposite of what it means at the moment:

1. Change their organisation, move Software away from the CFO, and bring all their IT Organisations under one umbrella.
2. Software has to be considered as craftsmanship. It must not be accepted that Software is created by single people and without tests.
3. Software has to be considered a product. That means you should think if you need to build that piece of Software yourself, with all strings attached, or if other companies can provide this product. Don’t do a project just to be cost efficient.

[1] Quite some time ago, two Greeks - Socrates and Glaucon, who was the brother of Plato - talked. Socrates was highly convinced that man was controlled by logic and goodness. Glaucon challenged that. He postulated that man was evil by nature and only acting well when seen by others. For this, he used the allegory of the Ring of Gyges. This ring will make its carrier invisible. Give this very ring to two guys, one just and one unjust, Glaucon said. We would find that the just man would start to act wrongly, for other people could no longer see when the honest man would do something wrong. Glaucon’s idea shows a very negative image of the human mind, but unfortunately, Glaucon was not entirely wrong. It is much more common to take shortcuts or not exercising the rigour we would expect of others. Pairing counters this by preventing invisibility. However, code reviews will not uncover shortcuts taken, as the reviewer cannot detect the intention of writing a line of code. ↩

Pictures by https://ccnull.de/fotograf/tim-reckmann under CC 2.0