5 ms·
I saw a post somewhere that said configuration data was added after the QE cycle, but before the broad push to the world
by supportengineer 2y ago
I saw a post somewhere that said configuration data was added after the QE cycle, but before the broad push to the world
- discreteevent 2y agoAny data that is interpreted is code. So the short answer is that they deployed code without testing it.
- brians 2y agoI 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?