I remember having a contradictory discussion at work about the design of a emulated eeprom driver for some embedded product. We had the flash memory hardware ra

I remember having a contradictory discussion at work about the design of a emulated eeprom driver for some embedded product. We had the flash memory hardware rated for a number of erase/write cycles. The question was what should we do when the cycle number is greater than that rated number. I said we should continue functioning and eventually raise a warning or something. But my colleagues were saying we should simply kill the hardware and brick ourselves. I was adamantly against this but they were citing safety concerns that maybe the flash could get corrupted and we weren't supposed to support that long of a lifetime anyway. We had a lot of safety mechanisms and redundancies baked in so data corruption would not happen. And my argument was mainly that, yes, if unrecoverable data corruption happens, brick it, but until the hardware forces you to close shop, the SW should continue running as long as possible. I don't know what they ended up implementing because I soon left, but I think they went with the self-bricking option. Anyways, I just wanted to share this nice anecdote and I can't help but think that maybe somewhere, some Intel engineers had some discussion very similar to my own.