Ford's Software Release Rhythm

Old Guy

Well-Known Member
Joined
Jun 8, 2021
Threads
8
Messages
195
Reaction score
120
Location
Hilton Head Island
Vehicles
2021 Ford Mustang Mach-E EX, RW
Occupation
Retired
Country flag
I appreciate the insight. For those who criticize “large established companies” not being able to change and adapt, I think there are many examples that disprove that. It may take a bit to get the ship turned, but they can turn and do a great job doing so, if they have the right leadership and commitment.
I’d still like to know why, in a car with a largely new electronics architecture, nobody thought to put in a modern, high-speed connection (such as Ethernet or USB-C to update the software. A 512KBbps interface in the 21st century is stupid. Frankly, I’d Ford developed an optional dealer-installed upgrade interface, I’d pay for it!

For my 2011 Ford Explorer we used to download Sync updates to a thumb drive and then load it into the usb port in the car with the motor running for half an hour or so. Sync was pretty much awful then but the updates fixed it. Not exactly OTA but it worked.
Sponsored

 

GoGoGadgetMachE

Well-Known Member
First Name
Michael
Joined
Jan 23, 2020
Threads
153
Messages
5,614
Reaction score
12,654
Location
Ohio
Vehicles
2021 Mach-E 1st Ed., 2022 Lightning Platinum
Occupation
Professional forum cheerleader and fanboy
Country flag
well, as the person that triggered this long write-up, I feel compelled to reply.

As a software developer and growing up with @Ford Motor Company, I'm concerned Ford's current approach to software development is not actually conservative. At best Ford's current approach is ignorant. At worst, irresponsible.
Those are both strong words, and both ignore that traditional manufacturing on any large product involves software development that doesn't match "modern" software development by necessity. Any hard real-time system in particular needs to be bulletproof (no pun intended) - "sorry the airbag didn't go off that time, we'll fix it in the next OTA" wouldn't work at all.

There's a major issue on this forum in general, one that you're displaying, which is the idea that all software on the vehicle is being done by the same exact people, doing the same exact things in the same exact way. That's not how any of this works, and it's not how any of it should work. "The Ford web site showed my car as an Edge and that quality issue shows why PaaK doesn't work well" or whatever.

Stating that all software development in the company should be done exactly the same way is madness, pure and simple.

A lot of the talk of Ford vs. Tesla OTAs is a conversation of the speed of releases. Not enough time for testing before release absolutely reflects on final product quality. However, the ability to consistently maintain and release software - the release rhythm - is equally important to software development and product support. I believe Ford's software release rhythm is not a result of the rigorous testing and reliability, but an inability to release software in a consistent and timely fashion. Hiding problems within the process, rather than identifying and addressing issues.
Release rhythm is a garbage metric, period. It's just garbage. If it takes an extra week for something to get done, then it's okay that it takes an extra week. Release rhythm means "ship it no matter what, we have a date", which is exactly what Tesla is doing.

Release Rhythm
While interconnected, the time to develop a release is different from release rhythm. Rhythm is how often a release is regularly distributed to the product. The less frequent the rhythm, the more disruptive a release is to the entire support apparatus for a product.

To explain, I'll use Semantic Versioning terms as they apply to iOS development. This can apply to most professionally developed software, but I'm picking an OS tied to a hardware device to better align with car development.

Semantic expresses a version number as MAJOR.MINOR.PATCH. The current release version of iOS is 14.7.1. MAJOR (14) and MINOR (7) are scheduled releases. MAJOR happens once a year, MINOR roughly every two months. This builds into the entire company the expectation of releases happening at these intervals. Not just releasing the software, but other areas of the business from MarCom to the most important: Product support.

PATCH is reserved for the unexpected releases. Bug fixing for cosmetic, quality of life, or most importantly security. Their very nature is unplanned as it's fixing issues discovered after release. The smarter managers schedule teams to be ready to react to these problems. Then one can cut the patch release and deploy that fix as soon as safely possible. While the release is unplanned, the regularity of releases makes deployment normalized and easier.
This is a fun diversion into SemVer, but it's irrelevant. Every single iOS x.0 release is basically buggy garbage. This has been true for years. But it's okay to ship garbage because release rhythm? Nonsense. I've been in the industry for over 25 years, and I've seen lots of different methods of software scheduling and management across many industries and many teams in those industries, including different teams in companies.

Tesla owners accept that their software will be broken in every release in some new way because release rhythm. TaxAct, TaxCut, etc. ship broken every single year because "we have to get it out before Feb 1" or whatever garbage date tied backwards from April 15. Every software release cycle that is strictly tied to rhythm is broken because rhythm is inherently unrelated to quality. I don't care if you agree or not, it's just reality as is demonstrated month after month, year after year, in project after project.

Ford's release rhythm isn't a rhythm. Nor is it semantic in any conceivable way.
What software versions are running in you personal Mach-E right now?
Do you know if there's updates available for the car? If so, are you even allowed to update?

If you received "Power Up 1.6" followed by "Power Up 1.4", you know the numbers in update notes are useless in explaining the current state of your Mach-E.

Why is the development and approval of software completely separated from the process of release? If the company is confident to release via service centers, why is it not considered ready for OTA? When an OTA is released, why is it a rollout over cars taking weeks? If it's not ready for all cars, why only let some out at a time?

I don't have insight to what's going on at Ford, but for the life of me I can't think of a valid reason to have two competing release channels for the same software release package. Each path with vastly different states within the channel.
The average person does not care about 1.4 vs. 1.6 vs. orange.pear.

As far as why not everyone at once, I'd have to say it's because real life doesn't match plan. Do you think Tesla doesn't do any testing at all? Of course they do testing... and yet their updates brick cars anyway.

<some stuff snipped here>

Nor is Ford in the position to deploy a patch for P0 problems in a reasonable amount of time.
in the auto industry, "P0" is life-threatening, recall-worthy stuff. Despite this forum being awash in complaints, the only thing that remotely comes close to that is all the stuff around 12V LVB issues, and the fix is out there.

Everything else people complain about on here is not P0, period. "I only got one fob" is not P0. "A convenience feature on the radio doesn't work" isn't P0.

I don't know what your software background is beyond what you said later in your post, but it sure sounds like you haven't done true industrial hard real-time, where failure can literally mean death, because you're bundling everything into one big bucket. Nothing in entertainment, education, etc. is hard real-time; hell, most of it isn't even soft real-time (although some entertainment e.g. video editing is).

The development models should be different because the basic problem sets are different.
 

hbirring01

Well-Known Member
First Name
Harman
Joined
Jun 22, 2021
Threads
37
Messages
336
Reaction score
313
Location
Baltimore, MD
Vehicles
2021 Ford Mustang Mach-E
Occupation
Software Engineer
Country flag
@Ford Motor Company needs to use a DevOps approach and use a pipeline with multiple dev, test, staging, early access stages and then finally prod. Thats how we do it in big tech! Ive used this approach at AWS and Microsoft.
 

macchiaz-o

Well-Known Member
First Name
Jonathan
Joined
Nov 25, 2019
Threads
168
Messages
8,157
Reaction score
15,299
Location
🔑 ]not/A/gr8'Place.2.store-mEyePassword[ 👀
Vehicles
MY21 J1 Premium RWD SR
Country flag
Those are both strong words, and both ignore that traditional manufacturing on any large product involves software development that doesn't match "modern" software development by necessity. Any hard real-time system in particular needs to be bulletproof (no pun intended) - "sorry the airbag didn't go off that time, we'll fix it in the next OTA" wouldn't work at all.

There's a major issue on this forum in general, one that you're displaying, which is the idea that all software on the vehicle is being done by the same exact people, doing the same exact things in the same exact way. That's not how any of this works, and it's not how any of it should work. "The Ford web site showed my car as an Edge and that quality issue shows why PaaK doesn't work well" or whatever.

Stating that all software development in the company should be done exactly the same way is madness, pure and simple.



Release rhythm is a garbage metric, period. It's just garbage. If it takes an extra week for something to get done, then it's okay that it takes an extra week. Release rhythm means "ship it no matter what, we have a date", which is exactly what Tesla is doing.



This is a fun diversion into SemVer, but it's irrelevant. Every single iOS x.0 release is basically buggy garbage. This has been true for years. But it's okay to ship garbage because release rhythm? Nonsense. I've been in the industry for over 25 years, and I've seen lots of different methods of software scheduling and management across many industries and many teams in those industries, including different teams in companies.

Tesla owners accept that their software will be broken in every release in some new way because release rhythm. TaxAct, TaxCut, etc. ship broken every single year because "we have to get it out before Feb 1" or whatever garbage date tied backwards from April 15. Every software release cycle that is strictly tied to rhythm is broken because rhythm is inherently unrelated to quality. I don't care if you agree or not, it's just reality as is demonstrated month after month, year after year, in project after project.


The average person does not care about 1.4 vs. 1.6 vs. orange.pear.

As far as why not everyone at once, I'd have to say it's because real life doesn't match plan. Do you think Tesla doesn't do any testing at all? Of course they do testing... and yet their updates brick cars anyway.

<some stuff snipped here>



in the auto industry, "P0" is life-threatening, recall-worthy stuff. Despite this forum being awash in complaints, the only thing that remotely comes close to that is all the stuff around 12V LVB issues, and the fix is out there.

Everything else people complain about on here is not P0, period. "I only got one fob" is not P0. "A convenience feature on the radio doesn't work" isn't P0.

I don't know what your software background is beyond what you said later in your post, but it sure sounds like you haven't done true industrial hard real-time, where failure can literally mean death, because you're bundling everything into one big bucket. Nothing in entertainment, education, etc. is hard real-time; hell, most of it isn't even soft real-time (although some entertainment e.g. video editing is).

The development models should be different because the basic problem sets are different.
Exceptionally well said, Mr. Gadget. Thank you.
 


ncaadam

Well-Known Member
Joined
Jun 21, 2021
Threads
6
Messages
157
Reaction score
185
Location
USA
Vehicles
Mustang Mach-E Premium Ext AWD
Country flag
Exceptionally well said, Mr. Gadget. Thank you.
honestly, i find it pedantic. i don't see Mr Gadget's response really suggesting any solution(s), merely just to say "no, your opinion is wrong and dumb."

release rhythm is just a framework to work from and OP is suggesting that it could help Ford's obviously lack major and minor bug fixing by consistently releasing something.
 

bwr1338

Active Member
First Name
Bruce
Joined
Apr 19, 2021
Threads
1
Messages
26
Reaction score
57
Location
Chicago
Vehicles
First Edition Mach E
Occupation
Retired
Country flag
As a software developer and growing up with @Ford Motor Company, I'm concerned Ford's current approach to software development is not actually conservative. At best Ford's current approach is ignorant. At worst, irresponsible.

A lot of the talk of Ford vs. Tesla OTAs is a conversation of the speed of releases. Not enough time for testing before release absolutely reflects on final product quality. However, the ability to consistently maintain and release software - the release rhythm - is equally important to software development and product support. I believe Ford's software release rhythm is not a result of the rigorous testing and reliability, but an inability to release software in a consistent and timely fashion. Hiding problems within the process, rather than identifying and addressing issues.


Release Rhythm
While interconnected, the time to develop a release is different from release rhythm. Rhythm is how often a release is regularly distributed to the product. The less frequent the rhythm, the more disruptive a release is to the entire support apparatus for a product.

To explain, I'll use Semantic Versioning terms as they apply to iOS development. This can apply to most professionally developed software, but I'm picking an OS tied to a hardware device to better align with car development.

Semantic expresses a version number as MAJOR.MINOR.PATCH. The current release version of iOS is 14.7.1. MAJOR (14) and MINOR (7) are scheduled releases. MAJOR happens once a year, MINOR roughly every two months. This builds into the entire company the expectation of releases happening at these intervals. Not just releasing the software, but other areas of the business from MarCom to the most important: Product support.

PATCH is reserved for the unexpected releases. Bug fixing for cosmetic, quality of life, or most importantly security. Their very nature is unplanned as it's fixing issues discovered after release. The smarter managers schedule teams to be ready to react to these problems. Then one can cut the patch release and deploy that fix as soon as safely possible. While the release is unplanned, the regularity of releases makes deployment normalized and easier.


Ford's release rhythm isn't a rhythm. Nor is it semantic in any conceivable way.
What software versions are running in you personal Mach-E right now?
Do you know if there's updates available for the car? If so, are you even allowed to update?

If you received "Power Up 1.6" followed by "Power Up 1.4", you know the numbers in update notes are useless in explaining the current state of your Mach-E.

Why is the development and approval of software completely separated from the process of release? If the company is confident to release via service centers, why is it not considered ready for OTA? When an OTA is released, why is it a rollout over cars taking weeks? If it's not ready for all cars, why only let some out at a time?

I don't have insight to what's going on at Ford, but for the life of me I can't think of a valid reason to have two competing release channels for the same software release package. Each path with vastly different states within the channel.


Support Problems
The only user accessible status is the Sync software build number, which is not actually any status of the car or the components. There's the shortcut to the diag screen, but the data isn't a complete picture and only if you're "in the know" of the feature.

When you roll up to a service center, it may take the tech hours to update due to the required battery procedure for updating a car. A lack of locally cached update data or high-speed Internet further complicates the problem. All of which disincentivises the tech from standardizing the car to the latest release. Resulting in known fixable problems and available features not delivered to the customer.

The "conservative" software development in practice means Ford is in the dark of identifying and solving software problems. Nor is Ford in the position to deploy a patch for P0 problems in a reasonable amount of time. The result is a wide assortment of possible combinations of production software versions that no one can track or standardize. The software stack Ford is testing will never be the conditions your car will be, present or future. The 1.7 update of today may not reach you till after you get 1.10.

Imagine how easier it would be for service centers if basic updates were the same as OTAs? More so if local file updates (download to a USB stick, then update car) were possible. The security needed are solved problems that make professional support folks focus on real technical service. Not busy work bogging down the shop, reducing capacity for servicing more cars, which reduces income for service centers. All because OTAs don't work consistently.

This week, Apple will announce iPhone 13 and (possibly) Apple Watch. The next iOS (and watchOS) will be out just before supporting devices from the past six years (iPhone 6s) and four years (Watch gen 3) respectively.

Ford released to customers the GT with software destined for the rest of the Mach-E line... at some point. As if only iPhone 13 could get iOS 15 for months ahead of every other device. If you think a car shouldn't be expected to have this type of long tail support line, then an iPhone's six year lifespan is longer than our cars.


Solving the Problems
The problems I highlight are not rested at the feet of any individual developer at Ford. In fact, my concerns are in part for a better work environment for the Ford team as a whole. What I point out are ultimately management issues. While I'm hopeful the recent hiring of Doug Field will help guide the company, one person alone can not change the tide. The intersection of the advances of software development can benefit not only the @Ford Motor Company, but the dealerships, the service centers, suppliers, and most importantly the customers.

I love how my Mach-E drives. It's the best car I have ever experienced with Ford in my entire life. It falls flat when I see folks around me choose Tesla above Ford when I can't reasonably demonstrate a better total experience than what Tesla provides them. A lot of good people worked on this car, and I want their work to shine. But we're not there yet. And I worry not enough folks in the Glasshouse realize this. Or don't listen to the folks inside the house saying this.


About Me
My software development work crosses education, entertainment, marketing/communication (MarCom), and retail sectors. My father worked for Ford though out my childhood in Dearborn (and a few years with Ford Aerospace in Newport Beach, CA). I gained a lot of personal prosperity though Ford, and I want to see the company succeed in bringing that prosperity to the current Ford team by creating quality experiences to Ford customers.

This started as a reply to a post, but then developed so large that I decided to make a new thread. I... have opinions...
You have stated the problem perfectly. If Ford wants to be an EV car company long term, they need to focus on the software and customer support. I love the physical car and based upon news articles they are doing everything right to keep improving the mechanical parts of the car, it is what the know. But the software and support to date is disappointing. I am really hoping the hiring of Doug is an indication that they recognize the problem and are trying to address it.
 

macchiaz-o

Well-Known Member
First Name
Jonathan
Joined
Nov 25, 2019
Threads
168
Messages
8,157
Reaction score
15,299
Location
🔑 ]not/A/gr8'Place.2.store-mEyePassword[ 👀
Vehicles
MY21 J1 Premium RWD SR
Country flag
honestly, i find it pedantic. i don't see Mr Gadget's response really suggesting any solution(s), merely just to say "no, your opinion is wrong and dumb."

release rhythm is just a framework to work from and OP is suggesting that it could help Ford's obviously lack major and minor bug fixing by consistently releasing something.
I don't think it's necessary for us to prescribe specific solutions. And we are too ignorant to do so anyway -- none of us are on development teams at Ford (afaik) and none of us are one of their directors of engineering.

Few of us know the true reality, though many here seem to think they do, or repeatedly make uninformed, sarcastic statements like "software is hard <snark>."

It's mostly couch quarterbacking as far as I can tell.

Michael (@GoGoGadgetMachE) made several points that I thought were well stated.

He is expressing an awareness that passenger vehicles involve large scale system integration across MANY teams, in one company or across several, that makes little difference at this scale. The end system has safety critical requirements. Problems are triaged by priority (and possibly severity) and are addressed accordingly. Not all problems can be solved, realistically. Focus on those that represent the biggest threats first.

And, just because one company releases software at a set interval no-matter-what does not mean that all companies should do the same, nor that this is the universal, best approach.
 

mpshizzle

Well-Known Member
Joined
Mar 22, 2021
Threads
65
Messages
1,274
Reaction score
1,589
Location
Utah
Vehicles
Mustang Mach E 4X
Country flag
In my opinion, whether they have organizational/development issues or not, the real problem here is a PR problem. They have done a very poor job communicating with the customers and training their support staff. The result is lots of misinformation, speculation, and reliance on "leaks" for any scrap of information. Case and point: the existence of this thread.

I understand why they're tight lipped. It gives them a lot of freedom on timeline and expectations. You can't break a promise if you never make one. Personally I think they've just taken it too far, and the proof is all the angst over software updates on this forum.

In my opinion if there's a hold up in development, it's better to tell the customers there will be a delay, rather than saying nothing ??
 

unhandled

Well-Known Member
First Name
Mathieu
Joined
Jul 28, 2021
Threads
13
Messages
176
Reaction score
173
Location
Stoke, Quebec, Canada
Vehicles
Mustang Mach-E Premium AWD ER
Country flag
A few additional comments:

- I agree we have no idea how the sausage is made at Ford, we can only speculate. We can only comment from a distance. Let’s assume they are a bunch smart people trying to figure things out over there instead of the opposite
- Communication in software development is tricky; overpromised/underdeliver and to say nothing is worse
- The fact there’s a lot of software to develop shouldn’t impact the release process. I.e. A large monolith blocks improvements from being released. Smaller independent releases unlocks that.
- Release frequency has nothing to do with releasing low quality software to meet an arbitrary date. The point is to frequently release the best version of the software as soon as new improvements/fixes are tested.
- A quick search on YouTube or the web will show plenty of examples on how DevOps is used in automotive/aerospace software scenarios
- DevOps principle applies to RTOS or any kind of embedded systems. You code, you test, you release
 

GoGoGadgetMachE

Well-Known Member
First Name
Michael
Joined
Jan 23, 2020
Threads
153
Messages
5,614
Reaction score
12,654
Location
Ohio
Vehicles
2021 Mach-E 1st Ed., 2022 Lightning Platinum
Occupation
Professional forum cheerleader and fanboy
Country flag
honestly, i find it pedantic. i don't see Mr Gadget's response really suggesting any solution(s), merely just to say "no, your opinion is wrong and dumb."

release rhythm is just a framework to work from and OP is suggesting that it could help Ford's obviously lack major and minor bug fixing by consistently releasing something.
If I were being pedantic, I'd explain how you are using that word incorrectly.

I am not in a position to know specific details in this case, and if I did, I am sure I wouldn't be allowed to talk about them.

I do know in general about large, multicomponent software development with hard real-time embedded components, and about modern DevSecOps (or SecDevOps or...), and about old-school "Agile" (DevOps minus the Ops), and about legacy waterfall development, including doing all of that and teaching all of that, across multiple industries. That is where I am coming from.

Someone that has not done coordination from basic firmware all the way up to mobile / web at the scale of Ford is simply not in a position to dictate to Ford how to do anything. There are literally dozens of modules from multiple manufacturers to coordinate, and Mach-E owners don't have the patience or tolerance Tesla owners do. Many threads on this site demonstrate that. Heck, just look at all the PaaK heartburn.

In my opinion, whether they have organizational/development issues or not, the real problem here is a PR problem. They have done a very poor job communicating with the customers and training their support staff. The result is lots of misinformation, speculation, and reliance on "leaks" for any scrap of information. Case and point: the existence of this thread.

I understand why they're tight lipped. It gives them a lot of freedom on timeline and expectations. You can't break a promise if you never make one. Personally I think they've just taken it too far, and the proof is all the angst over software updates on this forum.

In my opinion if there's a hold up in development, it's better to tell the customers there will be a delay, rather than saying nothing ??
This is fair but as had been beaten to death on here, Ford is in a no-win situation at the moment (one partially of their own making). Saying nothing is better than a never-ending FSD overpromise fiasco, but people blow everything out of proportion. Ford needs to find a middle ground to make the majority (which is not represented on this site) happy. For all we on here know, they have.

They've missed every vague deadline to date, I think? So I am not sure right new deadlines to miss would be helpful.

And there is no magic bullet, and no one person will magically fix software scheduling because software scheduling is always nonsense, beyond a day or two out, and even that is pushing it. That's why the rhythm method (*) is problematic. The best you can do on a schedule is small sets of coordinated fixes, which as someone (forgot who) pointed out is why nobody really does old-school-Windows-Update sets of decoupled individual patches in 2021. For what its worth, it seems "1.4.0" vs "1.6.0" were decoupled and we see how well that's gone, yes?

(*) snicker
 
Last edited:

GoGoGadgetMachE

Well-Known Member
First Name
Michael
Joined
Jan 23, 2020
Threads
153
Messages
5,614
Reaction score
12,654
Location
Ohio
Vehicles
2021 Mach-E 1st Ed., 2022 Lightning Platinum
Occupation
Professional forum cheerleader and fanboy
Country flag
A few additional comments:

- I agree we have no idea how the sausage is made at Ford, we can only speculate. We can only comment from a distance. Let’s assume they are a bunch smart people trying to figure things out over there instead of the opposite
- Communication in software development is tricky; overpromised/underdeliver and to say nothing is worse
- The fact there’s a lot of software to develop shouldn’t impact the release process. I.e. A large monolith blocks improvements from being released. Smaller independent releases unlocks that.
- Release frequency has nothing to do with releasing low quality software to meet an arbitrary date. The point is to frequently release the best version of the software as soon as new improvements/fixes are tested.
- A quick search on YouTube or the web will show plenty of examples on how DevOps is used in automotive/aerospace software scenarios
- DevOps principle applies to RTOS or any kind of embedded systems. You code, you test, you release
DevOps simply does not apply to embedded in many cases because you get one chance to release, period. There's no "Ops". This has improved in the last 20 years or so, but we know there are still components on the Mach-E that can't be updated OTA, and perhaps some that are not field-updateable at all.

There are no such thing as "independent" releases in real life multicomponent multiteam multivendor projects. Not to repeat myself some, but when Windows Update used to ship 10 "independent" patches a month (an average number to make a point), that was 1,024 possible combinations, which became 1,048,576 after two months, and so on. Do you think all those combinations were tested? Of course not. Microsoft has said so publicly. And that was just the OS, not the app layer or all the hardware drivers or... Even in a perfect DevOps pipeline world (which nobody had because nobody develops without outside OSS nowadays and that stuff is never fully tested as independent components nor properly updated), there are still component dependencies. (This is I admit somewhat pedantic because I am focusing on one word perhaps too much.)
 

GoGoGadgetMachE

Well-Known Member
First Name
Michael
Joined
Jan 23, 2020
Threads
153
Messages
5,614
Reaction score
12,654
Location
Ohio
Vehicles
2021 Mach-E 1st Ed., 2022 Lightning Platinum
Occupation
Professional forum cheerleader and fanboy
Country flag
I'm done with this thread because there's nothing more productive to be had with it. For the many of you in the industry that DMd me to thank me for saying what you know to be true and didn't want to say because XKCD 386, you're welcome. I have enough goodwill on here that I can burn some.
 

Jimrpa

Well-Known Member
First Name
Jim
Joined
Sep 10, 2020
Threads
230
Messages
7,009
Reaction score
9,299
Location
Wayne, PA
Vehicles
2021 Infinite Blue Premium Mustang Mach E ER AWD
Occupation
Retied (formerly tried to herd highly technical, independent cats)
Country flag
DevOps simply does not apply to embedded in many cases because you get one chance to release, period. There's no "Ops". This has improved in the last 20 years or so, but we know there are still components on the Mach-E that can't be updated OTA, and perhaps some that are not field-updateable at all.
I’ve read everything you’ve written very avidly. All I can say is that it all seems spot-on and in agreement with my experience. This final quote here completely aligns with what my intuition from too many years of experience is whispering in my ear, may be some of the major issues the program is wrestling with right now, and why Ford is being a bit quiet and a bit slow with us early adopters.

My biggest fear is that they may have discovered that some component/subsystem ended up not being fully BlueCruise capable and their production engineers and service engineers are trying to figure out how to cost-effectively get the upgraded hardware in. Ugh. I really hope I’m wrong.
Sponsored

 
 




Top