>
The world is full of important people performing vital tasks either without fail or wherein failures can be caught by other individuals and processes that serve as guard rails.Sometimes planes literally fall out of the sky. NASA caused a space shuttle to explode killing the entire crew. It is fundamentally untrue that anywhere in the world we have perfect people or processes.
> The solution isn't merely to be perfect it is to have a process that is tolerant of the level of imperfection that one would expect.
I expect that occasionally sometimes people will ship bugs and neither they nor the processes in place will catch them. This is a very minor bug. This is not the sort of bug that keeps engineering leaders up at night.
> For example it is perfectly reasonable that a someone could have foreseen it not clobbering a license file without prompting the user this could have brought the matter to immediate attention, its reasonable to suppose that if the first person didn't foresee it someone reviewing their choices might have thought of it, its reasonable that someone might have viewed the commit logs and noticed what was going on.
It’s really easy to point at others’ errors with the clarity of hindsight. But everything you said here boils down to just predicting the specific broken case, which is useless advice. Even your suggestion to check commit logs is useless unless you know the bug you’re looking for. It’s not as if Git spews errors when a license file is changed and it shouldn’t be. And if they knew what to look for in the logs, they wouldn’t have checked in the bug in the first place.
This team has doubtless shipped thousands of features. It’s unsurprising that they’ve shipped some bugs.
> None of this is an acceptable level of failure from people that drawing a 6 figure salary for a position of expertise or leadership.
You’re talking about a bug that caused a license file to be incorrectly changed and the fix is a revert. There is an audit trail of what happened and what repos were affected. It literally had no meaningful negative effect except to Microsoft’s image with the severest of critics, and to Jeff Wilcox’s holiday break. This is not a Therac-25 level incident.
I find it very interesting that none of the hyper-critical people in the comments here have discussed catching any broader class of issues. There are many comments criticizing the author for failing to check for an existing license file. (e.g.” How can someone be so bad at their job that they realize that a bot that writes to the license file needs to avoid overwriting an existing file?”) None of those comments that I’ve seen addresses the fact that adding a license file during a fork at all is probably an error. No, just criticism about this one case because someone told them about the exact observed bug so now it’s obvious.
The ability to criticize an error someone else already found is not valuable or constructive. And if this is the best you can bring, your judgement is certainly no better than the engineer who created the bug in the first place.
Disclosure: I’m a Microsoft employee.
Further disclosure: If someone showed up to a postmortem for my team with this level of condescension and no useful advice, I’d tell them to be quiet or leave.