As a Modex X owner I agree the GUI leaves a bit to be desired. Basic things like ordering the presets on the FM radio or automatically switching to streaming from FM when you go “up” past the last channel but going to another source when you go “down” (if I’m on FM I want to stay on FM!). Or having to press the defroster button twice for hot air (how in the world would anyone know this?). There are a bunch of little things like this that I can’t imagine would be difficult to improve upon. It looks like it’s just not a priority for Tesla, which is unfortunate. I understand they have a limited set of resources and I agree they should be focusing on Autopilot. However, it would be nice if they could spare a little more effort.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Under-staffed GUI/software staff?
- Thread starter insaneoctane
- Start date
-
- Tags
- Model 3
Zaphod
Galaxy President (former)
Far as I know, the defroster behavior has always been like that since the S, X and now 3. I guess sometimes it pays to read the manual.
Especially Nissan! What a godawful UX as much as I’m thankful for their efforts in EVs I partly blame them for amplifying the notion of range anxiety in early EV era through bad UI/UX around range and SOC.
Scrith
Member
Very true. On the other hand, the 360-view camera the LEAF has is something Tesla's huge vehicles have desperately needed since 2012...it's the only thing I miss from my old LEAF (and I miss it quite a bit...a huge Model X is quite challenging to park in a tight space, compared to a LEAF, at least).
sweter
Member
On one hand I agree, it seems like they're quite slow... After more than 2-3 years in pre-production (and more than a year in feature freeze) you'd think that the Model 3 software would be polished on release.
I highly doubt Tesla has software engineers hiring problems, even if they don't pay well (I don't know what they pay).
But on the other hand I often tell people that writing software is like having a baby and 9 women won't give birth to a baby in a month, so stacking engineers won't necessary speed up development.
I highly doubt Tesla has software engineers hiring problems, even if they don't pay well (I don't know what they pay).
But on the other hand I often tell people that writing software is like having a baby and 9 women won't give birth to a baby in a month, so stacking engineers won't necessary speed up development.
I will say this: the 3 software is far more polished, stable and performant at first release than the S software was.
comanchepilot
Member
actually, if you don't take care of your existing customers - someone else will.Let them work on Y and Semi. Jeez. Some people are so impatient.
My guess is there is less than one full time person on the UI. They throw someone at it when the must add something. Otherwise the software update history shows that no one cares. I can see them throwing someone into reskinning it just to make it seem like something has changed.
Yeah but if a stack of engineers is taking 24 months to have a baby, there MIGHT be a problem.
Yea I also don't think it would be a hiring problem, but I do think that they just don't hire enough in the GUI department. The browser has been a mess since forever, the media player, too. Sure some things like the rain sensing wipers take a lot more engineering work, especially with Tesla's solution, but some of those things are pretty basic.
I just think that the GUI isn't really a focus for Tesla anymore. Back when the S came out everyone marveled about the big screen, but right now other things are more interesting,
Other than that, Tesla knows that the people getting the first 3s were standing in lines, waiting patiently for way over a year to get it. You don't need a lot to satisfy those customers.
CuriousG
Active Member
I went straight into 7.0 series on the S so I didn't have those growing pains but let's compare in my 6 days of ownership.
I've had the media player completely lock up on me on more than one occasion where it required a reboot or it would reboot on it's own.
Bluetooth pairing issues on both platforms. Eventually worked out by not choosing to sync contacts and recent calls. Can only use dialer.
WiFi not enabled, rear heated seats not enabled, no shuffle, repeat, or direct advancing a song.
No calendar, browser, energy app.
TeslaFi reports that car has been offline numerous times but never received this message once on S.
Approaching car to unlock is hit or miss. At times I can get it unlock a good 20-25yds and other times I walk up to it and it doesn't unfold my mirrors but eventually will.
I've probably rebooted 8-9x already. 3 or 4 of it was due to Bluetooth. Performance has to deal more with they're using a much more modern processor and GPU to power the screen which leads to the snappy performance. I'd argue stability.
Tesla ought to take some of the UI consolidation to the S/X screen as there is much more space to work with and having an applet other than Navigation take up half a screen is just wasted.
TaoJones
Beyond Driven
That may be, and it’s nice that you love your car as many do. However, it’s not helpful to compare a suboptimal process to the lowest common denominator.
In the interest of Tesla maintaining its lead overall, it would be helpful to compare and contrast with those competitors who appear to offer more features already or who are likely to soon. Cadillac and Nissan come to mind.
Now, overall, do either Cadillac and Nissan have a compelling product relative to a Tesla? I would say absolutely not. Yet.
And the way to keep “yet” from happening is to illuminate weak processes as the OP has done and to keep illuminating them along with ideas for solutions so that other owners can continue to love their cars no matter what they choose to compare them to.
vdiv
Chief Grump
They may have more people werking on Easter eggs than UI and feature improvements
In all seriousness I see the onboard software platform and experience getting worse, enabled by the OTA updates. Tesla is already using the mobile app platform for advertising their energy products, how long do you think before that finds its way in the car? It already did with the battery uncorking. How long before they realize they can monetize on the captive eyeballs by "working with partners"? Navigation search results, destination charging and streaming channels are examples where this may already be happening.
And before you say, nonsense, Tesla is about the premium experience, consider whose premium? Consider what other software platforms (such as Apple and Microsoft, thanks Google!) have recently become.
Doom and gloom
In all seriousness I see the onboard software platform and experience getting worse, enabled by the OTA updates. Tesla is already using the mobile app platform for advertising their energy products, how long do you think before that finds its way in the car? It already did with the battery uncorking. How long before they realize they can monetize on the captive eyeballs by "working with partners"? Navigation search results, destination charging and streaming channels are examples where this may already be happening.
And before you say, nonsense, Tesla is about the premium experience, consider whose premium? Consider what other software platforms (such as Apple and Microsoft, thanks Google!) have recently become.
Doom and gloom
Just echoing some of my experience managing software teams - It seems to me that the M3 software is a relatively small, highly internally interdependent project, where tiny changes in many places can have all sorts of repercussions all around, surrounded by a large list of quite independent functionality .
By repercussions I mean, for example - if one "fixes" the behavior of lock/unlock in the garage as suggested in other threads, you may unacceptably 'break' it for those that park just outside their house. Changing if/how/when one reacts to wifi/bluetooth events may change car wake-up events, etc. Changing if/when one detects wifi may affect OTA schedules or AP uploads. etc.
Usually these highly cohesive things are best managed by a small dedicated team that has enough leeway to work hard but move slow (from a 'feature delivery perspective) refactoring the code massively as their own understanding of the domains and their interdependencies evolve. This is the team where typically more people won't help. Also where you want a few great engineers, not a bunch of average engineers.
It does seem, however, there are a lot of satisfaction issues and nits with peripheral stuff. (E.g. bluetooth audio resume) which seems highly parallelizable and incrementally solvable. Or side effects/bugs created by past code design that should've been caught in QA eg: (many car management in app -> "active car controller" pattern-> M3 unlock won't work if car isn't selected as the controller reacting to BT events )
So from my observation I would agree, it seems that the team could use a bit more help (not necessarily in quantity of bodies, but maybe some heavier weight software engineers, and not just 'developers' but QA folks doing acceptance and scenario testing too)
By repercussions I mean, for example - if one "fixes" the behavior of lock/unlock in the garage as suggested in other threads, you may unacceptably 'break' it for those that park just outside their house. Changing if/how/when one reacts to wifi/bluetooth events may change car wake-up events, etc. Changing if/when one detects wifi may affect OTA schedules or AP uploads. etc.
Usually these highly cohesive things are best managed by a small dedicated team that has enough leeway to work hard but move slow (from a 'feature delivery perspective) refactoring the code massively as their own understanding of the domains and their interdependencies evolve. This is the team where typically more people won't help. Also where you want a few great engineers, not a bunch of average engineers.
It does seem, however, there are a lot of satisfaction issues and nits with peripheral stuff. (E.g. bluetooth audio resume) which seems highly parallelizable and incrementally solvable. Or side effects/bugs created by past code design that should've been caught in QA eg: (many car management in app -> "active car controller" pattern-> M3 unlock won't work if car isn't selected as the controller reacting to BT events )
So from my observation I would agree, it seems that the team could use a bit more help (not necessarily in quantity of bodies, but maybe some heavier weight software engineers, and not just 'developers' but QA folks doing acceptance and scenario testing too)
Add to that this: behind the scenes I expect there is a massive effort underway to revamp the S/X codebase and consolidate it with the 3's (not the visual aspects, but the model behind the UI). They are probably also moving the S/X MCU module to the Intel based one from the 3 this year. They have a lot on their plate, it's just invisible.
I suspect you are correct about Tesla's internal architecture or lack thereof.
However, anyone building a software system like that in the last 10 or 15 years has been living in a cave (or working for the government). The entire thrust of software engineering for decades has been to modularize software development precisely so there aren't internal dependencies like the ones you describe.
hahahahahahahahahahahahahaha
(sorry, been on too many failed attempts at that very thing over the last 20 years. Shipping always trumps architectural purity, especially when company survival is on the line)
1. Carplay requires running a specific OS (QNX), or at least it did when they started. It's *not* simple to integrate without potentially adding another module.
2. Android Auto requires running Android.
I can think of a couple dozen reasons Tesla doesn't want to do either of those things. Most other companies are happy to cede their infotainment destiny to Apple or Android. Since Tesla wants to own the entire display experience, they will not do that, since they can't just carve out a bit of the software and hand it to Carplay/AA.
Similar threads
