Programmers - why so many bugs?

[Mirak]

I know I am probably going to regret the avalanche of nerdery that is about to ensue, but can anybody explain to a non-programmer why Ford is having so many bugs with SYNC, and why it is so slow to fix those bugs?

There are countless threads about (1) bugs that still exist after two years, and (2) how new releases not only fail to fix old bugs but introduce new ones.

I guess the first question is, is SYNC inordinately buggy, or is this to be expected and accepted?

What do you think is the reason for the bugginess? To my feeble mind, once you create a stable platform, you should be able to add features without effing up the stuff that already works, but that doesn’t seem to be the case with Ford. Yes? No?

And then there are the bugs that Ford has known about for years but hasn’t fixed. Why the delay? Is it really so hard to fix bugs that these cannot be prioritized?

Is it possible that part of the problem is outsourcing portions of software development to different countries / languages? I don’t even know that Ford does that, but I assume that they do. I remember when NASA crashed that probe into Mars because they failed to convert imperial to metric, for example.

Or is this a “you get what you pay for” situation and Ford hasn’t adequately invested in software dev?

Any insight for laymen would be appreciated.

Sponsored

 

[Logal727]

Anything connected to the internet never ships finished anymore sadly.

 

[Mirak]

Anything connected to the internet never ships finished anymore sadly.

And, again, to my non-programmer brain that would explain why new features might be buggy. But how is Ford breaking stuff that previously worked? And why is it taking so long to fix things?

These are not rhetorical questions btw… I’m genuinely curious why this is so hard.

 

[mdolan92869]

In my opinion, it started with Facebook and their mind-numbingly stupid motto of "Move fast, break things". They need new and shiny, who cares that the user experience sucks and things that used to work don't anymore. It's a matter of making sure the check boxes of cool new things is complete.

I know that bugs have existed forever, but it just seems so much worse lately.

 

[Logal727]

In my opinion, it started with Facebook and their mind-numbingly stupid motto of "Move fast, break things". They need new and shiny, who cares that the user experience sucks and things that used to work don't anymore. It's a matter of making sure the check boxes of cool new things is complete.

I know that bugs have existed forever, but it just seems so much worse lately.

Definitely not a new idea. When your goal is increased growth at any cost, this is just what happens, things ship unfinished, you fix them later (theoretically), unless you have issues with fixing things on the fly OTA like Ford did. Just overly ambitious which I don't know if it's a bad thing to be, but it does affect brand perception like in Ford's case.

 

[hack-e]

I suspect that some of the infrequent bugs are simply very hard to find the cause. It's always easier to fix a bug if you can readily reproduce it.

 

[MacherAWD]

As someone who works in software but not a programmer it is not their fault.
Programmers: We can have all the bugs fixed in the new release which doesnt add any features, will take us 6 months.
Some Uniformed executive: Ok, how about we push the release up to 1 month from now, no one cares about bugs, but just put something new so there is excitement
Programmers: Please let us just do our job, can you hear us....
Some Uniformed executive: Perfect, just tweeted out about the release, we ship in 3 weeks, just cut out the testing timeline.....

 

[grinder]

I am sure a few more OTAs will really help. The MME is still new for Ford. We just have to give them time.

 

[Kmp14]

As a software engineer, I am perplexed that some of these bugs are not fixed, like the broken FordPass departure times. We know FP can talk to the car since remote start always works. How hard is it to send those couple of bytes to updated departure times?

 

[ocr_salty]

Because if there weren’t any bugs at release the programmer wouldn’t have a job tomorrow.

 

[alexgorod]

It rarely, if ever, just "doesn't work". It "doesn't work sometimes" (doesn't load profile, connect to the phone, etc.). Bugs like that are much harder to recreate, and so to fix, and retest.

My theory is that some "services" are not starting correctly when the car gets started and SYNC is booted up - to make it faster, multiple of them are starting at the same time and sometimes stepping on each other toes.

But the bugs are getting fixed - PAAK works much better now than it did during the first few months of my ownership (end of 2021) after some modules get updated, AndroidAuto connects much more reliably after some recent OTAs, driver door opens without the need to open another one first

I prefer to drive the car now with all these hiccups than wait until all the issues are solved before the car becomes available.

 

[alexgorod]

As a software engineer, I am perplexed that some of these bugs are not fixed, like the broken FordPass departure times. We know FP can talk to the car since remote start always works. How hard is it to send those couple of bytes to updated departure times?

It works for me. How can it be?

 

[LM_COGT]

Disclaimer: this is external visibility, there's lots of things that could be true internally, but these are best guesses based on my time in hardware/software platform development.

0) Very likely a management structure that mistakenly thinks this is about "programmers." Software engineering, especially software designed for critical function on proprietary hardware, is a large systems engineering problem, and requires a multi-discipline approach to achieve success, programmers are an important piece, but just one piece of many.

1) Poor or missing Integration and Test capability. For quality releases on a routine schedule the integration and test areas are critical. How easy is it for a given software engineer to produce a fix, compile it to an engineering build, and run basic validation? Is there a continuous integration (CI) process in place ensuring that every commit to the codebase is regressed? Is that regression suite evolving and dynamic to cover the key issues learned from lab and field? Is there a high quality lab emulation of the platform that enables rapid and repeatable testability? On the culture side, is the test team treated as a key pillar in the engineering platform, or are they the annoying voices that keep complaining and dev engineers try to ignore?

2) Lack of well-documented and efficient process for creating and releasing product lines and patching those lines. How do program leads efficiently determine the right changelist to go into a particular release? Is there sufficient visibility into individual changes that enable for rapid assembly of release candidates based on clearly communicated release goals?

3) Weak or missing systems engineering group. This is a highly complex system, hardware, software, mechanical, UX. Having a team of engineers dedicated to the understanding of the end-to-end product and how multiple pieces fit together enables specialists in the different areas to focus on their strentghs, while being provided the support to understand how to fit within the larger picture. This has been well-known since early rocketry days in many places, but I have seen that often there is a blind spot in the org structure where software is not included in the systems engineering process, which is big mistake, software is a critical glue in modern systems and needs to be provided with the support of dedicated systems engineering resources to work best together with other teams.

 

[AZBill]

As someone who has worked on aerospace systems, and those have to be nearly bug free, the most likely issue is lack of good requirements. Also lack of testing against requirements and lack of robustness testing. Too many software engineers just start writing code, which is a completely flawed process.

 

[Deleted member 16048]

Honestly a lot of these bugs are inconsistent so it makes it really hard to have steps to reproduce. Along with this, clear logs after reproducing it are not really something they get from end users.

You can never have software be 100% perfect, things crop up a lot. The CarPlay "bug" for example. You're working with a system that is half if not mostly controlled by Apple. The "bug" could be iOS itself.

Now for issues they are aware of, it can come down to how many users are affected and does it pose a security risk. If not, it's going to be deprioritized. On top of that, they need to figure out if it's on specific configureations only or on any. Then continue to isolate the issue out. This takes a lot of time. There are bugs in iOS that have been there for years an Apple has no plans to address them.

Sometimes the issue is the amount of jungled coding itself too. Developers will sometimes just comment out code (Instead of deleting it, they make it inactive by making it a comment in the lines.) This adds so much bloat that it can cause issues since the computer still have to go through it and load it. Almost every app developer does this, even though it's not the right way.

Then after all that, it could be down to other priorities that are pushed by product managers that they want to get to market. A lot of the time, they hope the new feature will fix the bugs magically. (Sometimes they do actually.)

So there isn't a direct answer to why it takes so long. It's not an easy process to deal with, and on top of that a "bug" to you might actually be expected behavior to the engineers.

Sponsored