As an operator at a networking vendor this article really rang true. To me the whole article was a cry to re-think embedded systems design. He opened with relat

As an operator at a networking vendor this article really rang true. To me the whole article was a cry to re-think embedded systems design. He opened with relationship between feature-bloat and hardware performance in networking space. Won't your service be more performant if you avoid STP check on a routed network? Yet because of history and system design even if you don't use STP your hardware will perform check because of system architecture. Just take a walk through an IP or Ethernet header and look at how many of those protocols you actually use. Yet even if you avoid using them you can't 'disable' this checks in hardware. Refactoring seems to be hard or cost-prohibitive for network vendors, so it is avoided (at least until the next hardware generation is released). Even when engineering identifies an architecture problem, most managers will not take the risk of proposing refactoring. Maybe because it's more cost-prohibitive in an embedded system? Maybe because engineering teams implementing 20 year old protocols like ARP, Ethernet, STP, OSPF are in that position because they are inexpensive? His bit about DEVOPs is just trying to point out how QA for networking gear running well established protocols should not be a hard problem, yet for some reason gear gets released still with the same bugs you'd see in 2000. Why is this?