4 ms·

I think a reasonable explanation may be that other customers possibly have come to unknowingly rely on some of the bugs. Shipping a fix of all the bugs could ac

I think a reasonable explanation may be that other customers possibly have come to unknowingly rely on some of the bugs. Shipping a fix of all the bugs could actually break their code!

emeraldd 8y ago
Or their hardware, some of the impact of those bugs could be built into the physical hardware. By that point. Edit:fixed a typo.
- ethbro 8y ago
  Add in qualification of specific hardware inside specific operating conditions. The "move stuff and break stuff" crowd forgets there's a market for "move slow and rarely break stuff" too. So if you have qualified hardware w/ a certain driver version, you don't just ship a bunch of code fixes to a customer, you ship the bare minimum change set required to fix any specific issues they experience. Because you're sure as hell not recertifying every part revision with every driver version.
  - civilitty 8y ago
    I am definitely not one of those "move fast and break stuff" people, especially since I often have only a few months to design something that is expected to be in service until oxidation is a legitimate concern. My personal ventures are largely web based so I've also become rather too personally acquainted with the other extreme - the madness that is node_modules/, implicit *.d.ts imports, and browser impedance mismatches. The problem in the hardware industry is far more insidious. Unlike with software dev, there is no concept of "full stack" or "devops" in manufacturing. The entire field is so hyperspecialized that youve got people dedicated to tuning reflow temperatures to +-5C depending on humidity and local weather. No one person can have a proper big picture view of the situation so the entire industry is dominated by silos each with their own micro-incentives and employees competing with each other for notoriety.
gricardo99 8y ago
That’s absolutely true. Once you’ve delivered hardware with certain bugs that can be worked around by firmware/software, often that means the firmware/software teams don’t need or even want those bugs fixed. Fixing the bug means they’d have to go back and change their workarounds, which not only costs time/money, but adds risk that their may be unintended consequences and new issues.
- civilitty 8y ago
  Yep, there is a method to the madness. Something complex like making an electronic product is bound to have tons of pitfalls and most of these behaviors have rational (albeit twisted by economic incentive) reasons for why the things are the way they are. We were, however, an established client of Qualcomm and working on a new design so we explicitly asked for all bug fixes and they refused except for the ones we could name. We got "lucky" in that no other client had needed both bug fixes at the same time and when the build system broke, the one guy responsible for it was MIA so we got the whole source dump (they didn't even test their fixes together until a client found problems). I've used other Qualcomm products with different engineering support teams that are much better at source control, testing, and even devops but it's a very rare sight within the industry.

I think a reasonable explanation may be that other customers possibly have come to unknowingly rely on some of the bugs. Shipping a fix of all the bugs could actually break their code!

emeraldd 8y ago

Or their hardware, some of the impact of those bugs could be built into the physical hardware. By that point. Edit:fixed a typo.

ethbro 8y ago
Add in qualification of specific hardware inside specific operating conditions. The "move stuff and break stuff" crowd forgets there's a market for "move slow and rarely break stuff" too. So if you have qualified hardware w/ a certain driver version, you don't just ship a bunch of code fixes to a customer, you ship the bare minimum change set required to fix any specific issues they experience. Because you're sure as hell not recertifying every part revision with every driver version.
- civilitty 8y ago
  I am definitely not one of those "move fast and break stuff" people, especially since I often have only a few months to design something that is expected to be in service until oxidation is a legitimate concern. My personal ventures are largely web based so I've also become rather too personally acquainted with the other extreme - the madness that is node_modules/, implicit *.d.ts imports, and browser impedance mismatches. The problem in the hardware industry is far more insidious. Unlike with software dev, there is no concept of "full stack" or "devops" in manufacturing. The entire field is so hyperspecialized that youve got people dedicated to tuning reflow temperatures to +-5C depending on humidity and local weather. No one person can have a proper big picture view of the situation so the entire industry is dominated by silos each with their own micro-incentives and employees competing with each other for notoriety.

gricardo99 8y ago

That’s absolutely true. Once you’ve delivered hardware with certain bugs that can be worked around by firmware/software, often that means the firmware/software teams don’t need or even want those bugs fixed. Fixing the bug means they’d have to go back and change their workarounds, which not only costs time/money, but adds risk that their may be unintended consequences and new issues.

civilitty 8y ago
Yep, there is a method to the madness. Something complex like making an electronic product is bound to have tons of pitfalls and most of these behaviors have rational (albeit twisted by economic incentive) reasons for why the things are the way they are. We were, however, an established client of Qualcomm and working on a new design so we explicitly asked for all bug fixes and they refused except for the ones we could name. We got "lucky" in that no other client had needed both bug fixes at the same time and when the build system broke, the one guy responsible for it was MIA so we got the whole source dump (they didn't even test their fixes together until a client found problems). I've used other Qualcomm products with different engineering support teams that are much better at source control, testing, and even devops but it's a very rare sight within the industry.