Recent searches
Search options
Context- someone on the birdside are blaming #crowdstrike on DEI hiring
Here’s the thing folks. I’ve been coding 32 years. When something like this happens it’s an organizational failure. Yes, some human wrote a bad line. Someone can “git blame” and point to a human and it’s awful. But it’s the testing, the Cl/CD, the A/B testing, the metered rollouts, an oh shit button to roll it back, the code coverage, the static analysis tools, the code reviews, the organizational health, and on and on 1/3
It’s always one line of code but it’s NEVER one person. Implying inclusion policies caused a bug is simplistic, reductive, and racist. Engineering is a team sport. Inclusion makes for good teams. Good engineering practices makes for good software. Engineering practices failed to find a bug multiple times, regardless of the seniority of the human who checked that code in. Solving the larger system thinking SDLC matters more than the null pointer check. 2/3
This isn’t a “git gud C++ is hard” issue and it damn well isn’t an DEI one. 3/3
@shanselman Yeah, this is more like, "did y'all even fucking test this thing on an actual workstation? Like, sure, it passed whatever unit tests, but why didn't y'all just install it on a test machine/vm and make sure it didn't crash windows somehow?"
@digitalCalibrator @shanselman it’s possible that they did just straight up push from someone’s laptop to the CDN, but it’s also possible that the system they had used in good faith for a long time and had caught a lot of problems had a latent swiss-cheesey flaw in it. I think this is much much more likely to be a systemic flaw than one of individual or small-group malpractice or incompetence
@shaver @digitalCalibrator @shanselman Or watch and see comments from actual employees talking about the under funding of the testing group.
@shaver@hachyderm.io@alison @digitalCalibrator @shanselman as someone who has had to decide funding for a testing group I think that they are all underfunded against a defect-detection rate of 100%, but also generally misused in terms of applying them to the most important risks rather than the things that are easiest to test. it is an especially easy trap to say “our quality is good, we don’t need our QA tool investment to be this high” and then…it’s not good any more
@shaver @alison @digitalCalibrator @shanselman The right way to roll out a potentially crippling change (e.g. any kernel or boot code) is to target a few selected customers first, and then if it all goes perfectly, push to the rest. So yeah, this was an organizational systemic problem. The responsibility falls entirely on management.