[chiyc]

I appreciate you sharing your perspective! Mine's somewhat different having worked in another industry.

I worked in semiconductor manufacturing as a process engineer. What counts as bug in that setting? It's completely expected to have defects in the final wafer. They go through a QA process. Some die can be repaired but others are trash. Die also get graded and low quality chips go to customers with less mission-critical needs. There's also a department dedicated to investigating early failures in defective product from customer returns.

Personally, I viewed the product that I delivered as the wafers coming out of the steps I owned. High volume manufacturing is an ongoing process much like software development.

As an individual process owner, I had metrics and goals to meet but my processes fit into a larger system I didn't fully understand. Process development happened by incremental changes much like software feature development. We would convert a small percentage of the production line with a new change at one step like you might use feature flags, but we sometimes had to rollback changes when something unexpected came up at yield or test.

It might be more the nature of semiconductor manufacturing, but I view failures as part of the engineering process that comes up when we're pushing our tools and systems to new limits.

[Scramblejams]

Good point, (a) doesn't hold up when you're dealing with the bleeding edge. Plenty of experimental airplanes, designed by highly credentialed engineers, fell out of the sky on the way to producing today's safety miracle of commercial aviation. Similar story (hopefully usually less deadly!) with other miracles, like modern semiconductors.

[pwr-electronics]

When I worked in aerospace, there was a big, one-of-a-kind piece of metal where the fabricators had drilled a bunch of rivet holes in the wrong places. The structural engineers had to figure out if they could still use it. There's bugs in everything.

[torginus]

I think a good software analogy for this would having a piece of multi-threaded code that accesses a shared resource using locks.

There will probably be some waiting involved (analogous to defects). The engineer determine wha rate of waiting/working is acceptable, and if the software actually does perform like predicted.

If it does not, as in the wait(defect) rate is higher, it might indicate a genuine bug in the system (like locks not being released in a timely manner), or a failure of planning.