Comment by 0xcde4c3db

I'm not really a hardware guy (just a hobbyist), but I've worked with a few. As far as I can tell it's typically a mix of things, largely related to managing unique difficulties of hardware bringup and treating software development as part of the hardware product development cycle instead of really having its own planning/management authority. For example:

- Doing a hard fork of the software stack for every product family/generation/platform, because it's assumed up front that hardware differences/bugs and changes in product definition will require non-portable changes throughout the stack (e.g. things like GUI element sizes and line lengths are often hardcoded to fit the layout to a particular screen, various GPIO pins/buttons/LEDs/connectors change identity/significance, hardware gains/loses capabilities needed for a feature so UI elements related to that feature need to be added/removed/altered)

- Expecting the vast majority of development effort to be on shipping new products because already-shipping products are "in the can" and the big deals have already been closed

- Management belief that hardware is hard and software is easy (which is arguably sometimes rational from the perspective of managing product-dooming risks)

- Upstream vendors wasting developers' time with shenanigans around stuff like documentation (oh, you wanted the real manual that actually says what the registers do?) and firmware (some vendors apparently forget to mention that there is firmware until you ask your SE/FAE why something isn't working)

- Uncertainty around whether a given problem ought to be fixed in hardware or software