If Software Was Built Like the Cybertruck
If Tesla’s Cybertruck was a software project, it would be a perfect case study in modern development practices.
You know the ones. Get it shipped and we will fix the issues later. The only problem is that the fixes don’t always come, and it’s the customer who suffers. We are all aware of fixes that come late, and when they do they’re holding the truck together with metaphorical gum and tape.
It appears that is exactly what happened to Cybertruck and it’s panels.
Let’s take a look at the Cybertruck’s journey and then let’s ask ourselves the painful question. Is this the way to build anything?
Move Fast and Break Things
The Cybertruck was hyped as an indestructible machine, a paragon of modern engineering. So, it does feel shocking that its metal panels can simply fall off a truck which is bulletproof.
If this sounds much like software releases that’s because it’s exactly how some of the software releases we see behave.
I remember when we “accidentally” released an iPad version of our iPhone app, and we hadn’t tested anything with that screen size. The user experience? Still broken a couple of years later (although we’re “fixing” it, aren’t we?
When we bring these shoddy practices into vehicle production the impact is the same. If you ship first and deal with the consequences later the fixes aren’t always implemented.
When Apple ship and forget to protect their users’ privacy people in forums will tell us “That’s just how innovation works”. I’m going to push back against this. It isn’t. That’s how rushed engineering works, no more and no less.
Zero-Day
Tesla is no stranger to recalls. They’re running their company like a software company (although I really hope they have QA for the chassis) so they’re more than happy to ship half-baked features.
They’ve had to issue over-the-air software patches to prevent things like unintended acceleration (because sticking an accelerator pedal in a trim panel is a bold move).
Software engineers know this dance all too well. Remember Log4j? That little zero-day vulnerability that had every engineer sprinting to deploy a hotfix while pretending they weren’t panicking?
The thing is, you can’t do a CrowdStrike and pretend it’s all someone else’s fault when you’re shipping a vehicle that is going to move along the freeway at high speeds with literal panels falling off. Adhesive failure in software is when your modules don’t properly communicate to each other, in a vehicle it’s a massive level of failure.
Just like zero-day exploits, Cybertruck failures seem to appear out of nowhere. Yet one suspects a little more time in QA rather than hyping up the next feature might have produced a better experience.
Software Testing?
I’m not criticising the design of the Cybertruck, as tempting as that is. The fact is that the vehicle seemingly wasn’t tested properly before launch.
I mean who lets a car ship when the accelerator pedal gets stuck (other than Nissan)? Who would fail to realize that environmental conditions affect panel glue? And then say “this is ready for production”?
The fascination in getting things shipped without proper testing, and even dispanding QA departments is happening much too frequently nowadays. The Cybertruck is just the degredation of QA over time writ large.
Refactoring?
I truly hope that Tesla has a suitable platform for their vehicles. By that, I mean the chassis of the car. The issue is that in the case of the Cybertruck Tesla decided to ditch traditional vehicle design and go for a weird stainless-steel exoskeleton. Sounds cool, but functionally it’s a mess. It means that people working on the car need to adjust to the situation rather than use their existing experience, just like when my boss changed the framework we used for one nobody understands.
Remember that there are some use cases that require relational data and NoSQL simply won’t do. The Cybertruck is what happens when someone makes architectural decisions for marketing reasons instead of technical ones, and that is a pain I think all developers are used to.
Beta
Tesla launched the Cybertruck in beta, but they just didn’t call it that. That would be “hmm, fine” but this is a $100,000 of half-baked product. Instead of admitting it was unfinished, they let customers find the issues first.
Sounds familiar? It should. That’s what most software companies do now.
We call it agile development, but sometimes it’s just an excuse to ship broken software.
When users complain, the refrain is:
• “We’re iterating!”
• “This is a phased rollout!”
• “User feedback is part of the process!”
The truth is that sometimes we’re just selling an unfinished product. That’s not innovation. That’s abusing the customer base.
Hype
Musk claimed the Cybertruck had over a million preorders. Then, after launch, Tesla started offering discounts to get people to buy it.
Software companies do this by:
• Hyping up a new feature that doesn’t work yet.
• Announcing a revolutionary app update that nobody asked for, and calling it game changing.
• Sell a new product with a 10x valuation, only to pivot when users realize it’s essentially a scam.
We’ve all seen a big tech company drop a feature that turns out to be worse than what it replaced. (Looking at you, Google Chat.) The Cybertruck is just the physical version of this nonsense, and it’s time it stopped.
Are You Building a “Cybertruck”?
If you’re in software development, ask yourself:
• Are you actually testing before release, or are users your QA team?
• Are you prioritizing hype over solid engineering?
• Are you fixing the root problems, or just slapping on glue and hoping it holds?
Because if your answer is “We’re fixing it in production” you’re taking the Elon Musk road. You’re building the software equivalent of a Cybertruck.
Conclusion
Tesla’s Cybertruck is the physical embodiment of over-promising and under-delivering that we see in software development.
From zero-day patches to broken updates, we’re all shipping “Cybertrucks” more often than we’d like to admit.
The next time you’re about to push an update, maybe test it properly first. If the company doesn’t have processes that support you to do this push for them. Advocate for the user. Make sure we ship quality software, because if you don’t do so who will?