That's a little easier to do for software, harder to do in the context of building hardware, which is what the book was about. Circa 1980, around the time of t

That's a little easier to do for software, harder to do in the context of building hardware, which is what the book was about. Circa 1980, around the time of the events in the book, the time delays involved in making design changes to boards built from MSI building blocks were bad enough. Physical wire mods to a board took hours or days. New boards could be made in weeks or months. There was also some flexibility because parts of that design used PALs, which were easily reprogrammed. But in today's world the time cost of a re-spin of a CPU or a highly integrated SOC chip is huge. Months for simple changes, years for complete re-designs. Just look at the time estimates for hardware changes to x86 chips to mitigate Spectre and Meltdown. Some months for new microcode; many years for new silicon. Nevertheless, it's perhaps easier to let things happen and afterward think "I told you so". Because, unfortunately at most companies, if you try to impart those lessons earlier in the process, e.g. at design reviews, you quickly get the reputation of not being a "team player". Sounds crazy, but that's simple human nature.