When it comes to Linux creator Linus Torvalds, he likes the way speculative execution improves performance. What irritates him is the fact that not all incorrect calculations are completely discarded — this is what turned out to be the root cause of bugs like Spectre and Meltdown. … The fact that the developers of operating systems and kernel developers had to manage the fixes is something that irks him a lot. “It’s not fair. When we screw up, it’s fair, we have to fix it. But it feels less fair when we have to fix someone’s else’s problems,” he added. fossbytes.com September 3, 2018. Linux Creator On Intel CPU Bugs: “It’s Unfair. We Have To Fix Someone Else’s Problems.” Image: www.orosk.com

I secretly loved it. We had gotten our software working so well and had done it so early on in the project that when hardware issues arose, they became the critical issues for the project. In the past when hardware issues arose, they were seen as something to fix, but because the software was always running so far behind and was so buggy, that software was always the critical issue. Over the years, the common wisdom was that we didn’t have many hardware issues but always had lots of software issues. In relative terms, that might have been true. In reality, once we got software under control, hardware became the critical factor and yes, the software was just about always called upon to cover up or fix the hardware issue especially towards the end of a project.

However, having to fix hardware problems using software workarounds or solutions was always a cost-effective way of being flexible in a project. Software changes were a lot less expensive and faster to implement and test than most hardware changes. While as a software guy, I liked to poke fun at the hardware team, we also accepted our special role at being able to adapt hardware with software to work in situations that were not anticipated for when the hardware was designed. I recall one case in my Air Force career where our organization was able to creatively alter an algorithm to account for a flaw in a satellite’s sensor and save a satellite that had cost tens of millions of dollars. We didn’t think it was unfair that we had to fix it. We relished the opportunity.

Do you appreciate the flexibility that software brings to your project without abusing it as a continual fix for low quality in other parts of the project?