5 ms·
Indeed, the changing user needs aspect is inevitably the cause of so many memory corruption issues when old code, that's only really understood by that one or t
by mlindner 4y ago
Indeed, the changing user needs aspect is inevitably the cause of so many memory corruption issues when old code, that's only really understood by that one or two grey beard still at the company and about to retire (or have already retired), needs to be changed. The change is put in and everything looks fine and then it's given to the customer who eventually complains of rare crashes on their previously-working-just-fine hardware. (Oh and you don't find out about the crashes until almost a year later given the long release cycle so have long forgotten what you did a year ago.) Inevitably it's used as an avenue for the sales engineers to upsell the customer on new hardware claiming their hardware is out of date. The software engineers all know this is a white lie given that the same software runs on both pieces of hardware and the hardware didn't actually change much.
It just ruins you over time and makes you wish you never had to work in this business.