Making car software as a service instead of a sale is an inevitable shift for the smarter car revolution. But how? Let’s explore the 1st step to the machine city 😉.
Two ships to two directions
“There is no easy way to say this. So, I’ll just say it. I have to take one of the ships… to machine city.” — Neo, The Matrix Revolutions
In a sense of The Matrix Revolutions, Zion is falling under heavy attack. Neo asks for one ship to go to the machine city to pursue a hunch. It’s a suicide mission for sure. No one knows how Neo may succeed. Not even Neo himself. But, “I’ve to try” said Neo. It’s a crazy bet with a big stake, the 50% of remaining resource. Which may use to help Zion instead. Against all range & opposition, Captain Niobe gives Neo her ship. What a brave & decisive leader.
After some explorations, Ford will not spin off its EV business as Ford CEO, Jim Farley said on Feb 23, 2022. I can imagine how many similar debates were among Ford executives ahead. I could only hope Ford will spare some to pursue 10x crazy ideas too. Because digging into the same hole harder never gets anyone out of the hole.
To be clear, I’m not naively suggesting anyone to bet all-in or even a high stake on the crazy ideas. Instead, one can consider a portfolio management strategy, such as Google’s 70/20/10 principle: 70% on the core challenges, 20% on the adjacent opportunities & 10% on 10x ideas. The actual ratios should be adjusted according to the context, instead of mechanically applied.
Scale with machines 🦾
Coincidentally, salvation is to reconcile with machines to fright the common enemy 😉. The car software development productivity gap will continue to expand quicker than any organic grow or incremental improvements. Furthermore, The Mythical Man-Month remind us “adding manpower to a late software project makes it later” nicely. Don’t fall for the trap, even it’s easy to fantasize to add headcount as the silver bullet.
While Web service & app development have been improved significantly by automation in the past decade, the struggle continues for device development because of the HW/physical limitations. Even with many incremental improvements, the industry is still developing device software pretty much like 10 years ago, unfortunately. Why does it have to be this way? Only if someone has a ship to the machine city 😉.
Stop sending a human to do a machine’s job
How will you guess the confidence level to deliver on time & on quality? All other things being equal, their capability of development workflow automation may provide a hit.
1. Continuous Build
Most companies do this already. I’ll run away from any team without this, or build one first when founding a startup team.
2. Continuous Testing
Most companies do this but with very low coverage & frequency. So, engineers add honest mistakes during development cycles. Therefore, each QA cycle discovers many new surprises. Consequently, more time & difficult to burn them down. This may still be scalable by HW labs for big companies, such as Facebook’s mobile device lab. Just considering at least 10x cost & space requirements for cars, which company can afford that at the scale. Do let me know if you know one 🙏.
3. Continuous Integration
To do CI, a code change needs to be validated somehow before merging into the code repository. This is impossible if a company is already doing the bare minimum on CT because engineers need to wait for it to iterate or merge a change. Waiting hours for that will do more harm than good, such as lower development throughput, more frustrations, bigger patch size…
As CI is already very rare for device system development, I’ve not seen anyone do Continuous Delivery at scale. But, why is device system CT & CI at scale so hard for device development?
1st “silver” bullet
To be clear, this is not the silver bullet that can solve all problems. There is no such thing. But, emulation is the first key to opening the door of other possibilities. By turning the device HW problems to be software ones, you remove the physical limitations to scale. Which has been the solution for mobile app development to scale for a while. Only it is just too difficult to build a high fidelity one, and too cheap of HW alternatives for mobile. But for the car software revolutions, this may be the only sustainable step forward.
Full Disclosure
The opinions stated here are my own, not those of my company. They are mostly extrapolations from public information. I don’t have insider knowledge of those companies, nor a whatever expert.
