Are Projects Still Needed or an Old-Fashioned Relic of Yesterday?
Part 4: When Software Defines the Value of a Product
One trend is clear — and it’s irreversible.
Machines are learning to think. And they’re getting better at it every day.
If you’re expecting me to proclaim the end of humanity or prophesy the rise of artificial intelligence as our new ruler, I’m afraid you’ll be disappointed.
I genuinely believe — and I mean this seriously — that computers can, in the long run, be a gift to humanity. There may even be a chance they protect us from ourselves. Sounds naïve? Perhaps. But a little optimism never hurt any engineer.
And given everything happening in the world right now, we could certainly use some.
Unfortunately, that’s hope, not scientific insight.
I won’t attempt a prediction of that magnitude — I lack the data, the expertise, and, honestly, the kind of ultimate abstraction required for it. And I suspect I’m not alone in that.
What I can do is to examine a time horizon for which I have clear data and solid evidence. A horizon close enough to be concrete and far enough to be truly relevant.
Today, I want to talk about what this means in practice — for the product, for its development, and for everyone involved in it.
So let’s start with the trend itself.
Muscle and Mind
Muscles have been largely mechanized.
For as long as we’ve walked this planet, humans have tried to shape the physical world to our will.
We transport heavy loads. We generate heat, light, and motion. We protect ourselves from weather, natural force and from each other.
For millennia, we relied almost entirely on our bodies to do this. Our bodies provided the energy, the strength, and the intelligence needed to reshape the world, step by step, according to our wishes.
And then, in the blink of an eye on the timescale of human history, everything changed.
I find it fascinating every time I reflect on just how short that interval really is.
It’s been only about 300 years since we invented machines capable of taking over physical labor. Since then, they have steadily lifted the sweat from our brows and delivered enormous gains in efficiency.
And it’s been only about 50 years since we began using electronics and software to process information — helping our brains work more efficiently.
Or, alternatively, flooding them with more information than they can handle. I’ll just say: social media. (ok, that doesnt belong here, but I couldn't resist)
With that, I’ve essentially sketched the development path of the mechatronic products we’re here to discuss.
Initially, the focus of electronics in machines was on unlocking new use cases, using energy more efficiently, and simplifying how humans operate machines.
In my last article, I put forward a thesis that, at first glance, sounds provocative:
The requirements of a physical product are far less volatile than the software requirements.
Had I claimed that 250 years ago, I would have been laughed out of the room — rightly so. Back then, mechanics was the dynamic frontier.
That I can confidently argue the opposite today is a testament to how remarkably successful engineering has been. We’ve climbed high up the curve of mechanical innovation — so high that we’re beginning to see the ceiling.
We are approaching saturation — a point where more no longer means much more.
The pace is slowing — not because engineers have run out of ideas, but because they were so effective in the first place.
The physical world operates by natural laws — and those laws are largely understood. Thermodynamics sets a hard upper limit on motor efficiency. Material physics constrains how much load can be borne. The remaining room for improvement shrinks; gains become increasingly marginal.
Of course, open frontiers matter. The electrification of transport is a good example.
But even there, the requirements are broadly known, the physics understood, the development more gradual than revolutionary.
When it comes to logic —meaning what machines can think and decide — the picture looks entirely different. Here, we are still at the beginning.
The Hardware Is Learning to Think
With the arrival of microelectronics in machines, a new era began. Slowly at first — then with extraordinary momentum.
Suddenly, it became possible to combine sensors, actuators, and computing units in a system, orchestrated by software.
The machine acquired something like a nervous system.
I find the comparison with the human body genuinely helpful here.
The mechanical, hydraulic, pneumatic, and thermodynamic systems of a machine — these are its skeleton, muscles, and metabolic organs. They provide force, movement, and energy.
Sensors, cables, microelectronics, and software, on the other hand — these are the sensory organs, the nervous system, and the brain. They perceive, process, and trigger action.
The more of the latter enters a machine, the more it resembles the human body — and in many dimensions, even surpasses it.
But there is one fundamental difference from the biological model, and it’s highly relevant for developers:
The human body has one central control unit: the brain. One. Just one.
Highly complex machines — take my beloved trucks, or equally, passenger cars — operate with a decentralized network of many system and domain control units, connected through gateway controllers in a specific architecture.
This represents enormous complexity — and it demands a clear methodology from developers to fully grasp the system as a whole and systematically bring it to life.
That methodology is called Systems Engineering. Remember that term. It will be worth your while.
I’ll return to it repeatedly in the articles ahead and go deep into the subject matter.
Separating the Stable from the Fast-Moving
When physical development loses momentum while logical functions grow exponentially, one idea becomes obvious: why not systematically separate the two domains?
Keep the mechanical part stable. Evolve the software layer at high frequency. Both simultaneously, but independently.
This requires a centralized electronics architecture — and equally, a centralized software architecture.
And with that, the machine too finally gets a brain — just as we humans have.
For this to work, a fundamental structure is needed:
There must be a software layer that reliably handles the core functions of the physical and electronic hardware — something like the machine’s brainstem.
Above that sits an operating system that serves as a stable platform — a foundation onto which software applications can be docked, modified, and extended without touching the underlying hardware.
In the automotive industry, this new architecture has been given a name: Software Defined Vehicle.
Behind this term lies a far-reaching prediction: that the transport function will become secondary for customers in the future.
They want to work in the vehicle, be entertained, sleep — while their position on the map quietly changes.
The car will then be defined not by driving dynamics, efficiency, or safety, but by the software the customer consciously uses and experiences while driving.
Whether that comes to pass remains to be seen.
But the underlying trend is real — and far broader than the automotive industry.
The architecture of the machine continues to approach the architecture of the human body — and as we know, that’s an extraordinarily capable concept.
For developers, this means one thing concretely: welcome to the world of parallel processes.
The hybrid development process will continue to exist — as I outlined in my last article.
Alongside it, a purely agile development process will emerge — for the topmost product architecture layer: the Software Application Layer.
Both processes run simultaneously, overlap — and yet operate at completely different speeds, with different methods and different characteristics.
I frequently encounter the view that in the future, only the agile process will remain — that the classical development approach will simply die out like the dinosaurs.
I consider this a dangerous misconception — and I want to raise your awareness of it.
Ask yourself, deliberately, with every development initiative: What is this actually about?
Is the physical substance of the product evolving — or is this “only” about the application layer?
Those who can answer that question clearly gain immediate clarity about the right approach — and dissolve a great deal of apparent complexity in the process.
And Then the Machines Start Talking to Each Other
Before I close, I want to address one capability that has defined us as humans for millennia — and that machines are now beginning to acquire as well.
The ability to communicate with each other and to coordinate action accordingly.
That is precisely what “Industry 4.0” is about: the networking of machines through external computing resources.
Centralized storage and processors in data centers somewhere in the world, with which machines exchange information in real time via wireless connection over the air.
The machines are talking to each other. And they’re learning as they go.
And with that, we come full circle back to my opening premise.
Here, machines can do something we humans simply cannot: communicate with thousands of other machines in milliseconds, share data, synchronize decisions.
An advantage that becomes unbeatable as connectivity grows.
But — and this matters to me — these systems do not emerge on their own.
Many more years of human developers will be needed to design, implement, and make these architectures usable.
And I think you can sense that this is anything but trivial.
In this context, Systems Engineering gains an entirely new dimension and project management, too, must adapt to this reality.
I look forward to exploring this together with you in the articles ahead.
I hope this article helps you place the developments of the past — and those still ahead of us — into a coherent framework.
With that understanding in hand, you can navigate the jungle of growing complexity and reach for the right toolbox in any situation.
Here are the key takeaways from the last few articles at a glance:
Some products are heavily physically driven — for them, the classical development process remains the right approach, even in the future.
The vast majority of products are mechatronic — they require a hybrid methodology.
To gain speed, the Software Application Layer will increasingly be decoupled and developed agile — independently of the rest of the product cycle.
Cross-device networking creates highly complex systems — for which Systems Engineering is not optional, but essential.
So — Do We Still Need Projects?
Projects will still exist in the future — but they will look very different from the ones we know today.
What lies ahead is a coexistence of hybrid and purely agile approaches, operating side by side.
At different speeds,
on different system levels,
and with fundamentally different logic.
Navigating this environment is not simple. It requires clarity about what kind of development you’re actually doing at any given moment.
The complexity is real. But so is the opportunity — for those who understand the terrain.
Stay tuned — there’s a lot more to explore.
If you have any comments or feedback on this topic, please write them in the comments.
or send me a direct message.
We can also chat about it.
I’m looking forward to hearing from you!
If you found this article helpful, don’t forget to share it with others who might enjoy it too!
And if my newsletter resonates with you, please consider sharing it with others.