Just a note on this back and forth with software. At a high level, I believe people highly underestimate the effort and complexity of the Lucid's system. There are a lot of demands and juggling priorities being asked of the same "computer". As someone who expected to launch a database to market, built from the ground-up, 9 months ago vs still ironing out issues today, let me assure you the number of hidden gremlins, last minute architecture reworks due to bugs, and architecture cleanup due to performance requirements can and are unexpected and time consuming in these types of systems.
As an engineer observing from the outside Lucid's software, I suspect the following:
- Multithreading Is being used. This is one of, if not the single hardest piece to get correct. All those things you expect the car to do have to be coordinated and synchronized safely in the sheer chaos of any and/or all of them trying to do it at the exact same time. Fixing one bug, or even worse undefined behavior, often reveals a whole new set of bugs from previous incorrect assumptions.
- Event driven architecture. A system, including user interaction, gets triggered in one part of the code to be queued and processed in a completely different part of the code. This is the defacto design for most UI/UX systems with heavy backend processing (eg. audio, dream drive, hardware sensors, Lucid Assistant, etc.). Complex and hard to replicate as you have several things firing essentially random with random timings (eg. hard to consistently pinpoint and replicate the source of a bug).
- 3 known complete rewrites. Major versions of 1 and 2 for the Air. 3 for the Gravity. All of these rewrites take a ton of time of "stalling out" in the hopes, not guarantee, of addressing technical issues, bugs, and features not currently possible. This often means all new code that needs all new testing and equally long periods to find and iron out the "wrinkles" aka bugs.
- Technical Direction and Prioritization. Lucid has cycled through a number of "captains" directing the efforts and even associated "crews" for the software development. An organization must prioritize performance and long-term sustainability while equally compensating and rewarding employees to do so. Given the churn and overall focus on the driving experience (eg. the physical experience), I suspect a ton of resources have been allocated and prioritized to the in-house traction control systems and other hardware systems. The focus on long-term sustainability and performance of the user facing software only a more recent focus (post mad dash to get Gravity and UI/UX 3.0 out the door). Meaning all the sub-optimal decisions will plague the current software until addressed costing time and resources at some factor larger than "just doing it right" the first time.
While I would hope Lucid would have highly talented software engineers designing the best system from the get go, the entire industry has been plagued with indoctrination of Object Oriented Programming. This has led to abstraction hellscapes in code, bloated code, highly tangled and coupled monstrosities unable to be properly tested except with mock testing (eg. not real tests), and ultimately code that is not performant. We see this in the requirements for faster hardware nearly every year to make our phones feel "snappy" again. Old computers unable to use modern OS systems for Web browsing, watching videos, and document based work.
All of this to say that these same practices are almost certainly present in Lucid's codebase despite best intentions because that is the indoctrinated practices with excellent engineers who know nothing better (and every manufacturer's codebase including Tesla who required hardware upgrades for software updates due to bloat).
If you can't live with the current bugs for some period of time, get a different car whose bugs you can deal with for an extended period of time. If software is that important, prioritize a legacy manufacturer who is unlikely to update or address bugs in their cars because that means stable and known bugs vs. potentially having bugs fixed + new features for the trade-off of potentially new bugs.
www.thedrive.com
