Orchard Lab

A place to share my thoughts and learnings

Software Sometimes Is Annoying

Posted at — Apr 16, 2022


This is the start of the story. Unfortunately, this is the end of the story too.

About two months ago, this the above screen popped up in my Tesla. I thought, well, look how smart this car is. It can even tell me the tire’s wear conditions without using coins or special tools to measure. Software is amazing!

I took the car to the dealer, as expected, they replaced two brand new tires on the rear side, since the front two tires are still pretty decent, so they kept it there (to save me some money). Awesome, brand new tires, peace of mind.

The only problem is, the warning still stays there. Because the rear side is too new, so the difference between the front and the rear is still big enough than the software’s configuration. And there is no local reset or override option in the car’s software system itself, this is controlled by the “centralized” configuration in the Tesla software. The service person explained to me that the other Tesla team was well aware of this issue and working a fix in the future software updates, but they (dealers) have no way to fix it.

The upside is that this could be fixed automatically over the wire through a software updates. The downside is it might takes a long time or forever.

As a software engineer, a change might not be that strait -forward than it looks. Yes, it’s a configuration change, but I guess we can’t just change the configuration globally (again I am not a car person, so maybe what I am going to say here is totally rubbish). There will be discussions around should we allow local overrides or not, how much buffer should we allow, how do we expose this local overrides, shall we only allow technician to do it or any car owner to do it. Once we finalized the design for the change, we would allocate resources to design the UI and put the work in the pipeline. Anything more important happened could again de-prioritize this and move it into the backlog.

Everyone has a different opinion regarding to the importance of a software fix. From customer’s perspective, any feature we rely on is worth the fix. But what bothers me the most is the “false positive” signal it shows (all the time).

Because of this always on warning on the dash, after couple of weeks of driving, it numb my brain to pay any attention to any warnings anymore. Cause I will by default treat anything showing up there as “false positive”. Depending on the person, it might make some people more ignorance or more stressful.

I can’t remember even once in the past that I sent my car to the dealer to clear warnings in the dash ended up they are saying: “Sorry our software teams are working on it, we can’t do anything about it now.” As a software engineer, this makes me sad. I can feel even a simple decision we made might makes some users miserable using it.

Software in a way empowers people to have more customizations than the analog world, but at the same time, it also makes us feels helpless by using it. Why is that?

I think there are so many factors involved. There is no single one or two things 100% determined the way software has to be. I will just share some of my incomplete thinkings around this.

I think one of the reason is the centralization, software becomes more and more centralized, there is only one team working on this significant feature which applies to every car running on the road. Every company eventually becomes a software company. People design car softwares in California might rarely think of people driving it everyday in the freezing places. They are designed centralized while distributed globally. Why it has to be centralized and uniformed? Because it’s cheaper to do so.

Another reason I think is the lacking of standard or componentized structure. Replacing a compatible wheel or tire is way more strait-forward than replacing a piece of software component. Because most of the time, tangible things are an open book while the software is a black-box. From this perspective, I think WebAssembly might help in the future software design, especially for things with interchangeable components. Yes, there is for sure no silver bullet.

I am a huge fan of Dynamicland. One thing I interpreted is that it exposes the black-box software to the outside. And enable people to change, transform and collaborate on top of it. At the same time, software enables the dynamism and make the regular object like a living thing. I don’t know if and how this could applies to the car software, but I would be more than happy if it can enable me to get rid of that annoying warnings.