I like that framing! Alternately, they did not ever test the ability of their code to accept arbitrary configurations. That totally could have been done, allow

I like that framing! Alternately, they did not ever test the ability of their code to accept arbitrary configurations. That totally could have been done, allowing fast config pushes. But it wasn’t. So as a reliability engineer, I’d point at that change: configs were originally expected to be tested, so the parser was only tested to be sure it showed issues on pre-release testing. Later, they started shipping configs faster than their release cycle, but didn’t check to requalify the parser for this new requirement. Behind that, I’d look at the engineering and product culture that had that happen. Is there a list of what’s been tested for what purpose? Was the expectation that configs get tested like software written down someplace, and do the roles who scheduled that config release read that place? Who is organizationally set up to notice this, and why is it a director-level IC straight out of xkcd 2347?