> Second, it should be the default that the status quo is a bad thing; instead of justifying why something should be done, the burden of proof should rest on th

> Second, it should be the default that the status quo is a bad thing; instead of justifying why something should be done, the burden of proof should rest on those who believe things should remain the same. This is a downright dangerous view. My job as an engineer is managing complex systems, quite often in maintenance mode. I have fielded my ideas that come from people that do not understand the full complexity of the system, and thus, cannot understand why their idea is bad. It's not just that I (as a maintainer) have to explain why their idea will not work: I first have to teach them enough about the system for them to actually understand the system, and then explain how their idea would interact with the system, and the consequence of that; that's often closer to "here's how you can mentally simulate the system" and perhaps a little of "and a naïve simulation would think this, but remember parts A, B, and C have properties a, b, and c, and those interact to do X, which is slightly surprising (albeit straightforward once you think about it)" There's often precious little time for that, and it can often suck the limited oxygen out of the debate and thus, out of other ideas that might be better. It is much more useful, in almost every situation I've ever been in, for ideas that are being suggested to be well-researched in the status quo. "The system should be documented!" you might cry: it is. For example, we maintain a system that uses a load balancer. It's documented (as part of the system) that the load balancer is part of the system. It's documented (as part of the load balancer) how the LB works. And then we hit issues such as "SNAT port exhaustion" that requires you to have read enough of the documentation that you have a mental model of "load balancer" that is more detailed than "it balances the load" and realizes that an SNAT LB would have operating limits and that the symptoms we were seeing could be the result of all this coming to a confluence. It's not trivial. (And, there is a difference between this point and the later "value experimentation over perfection", which I do agree with. Experimentation, to collect data to aid good arguments to changing the status quo is of course a good idea. But the second point strikes me as "the status is inherently bad" and one should not even seek to understand it, as implied by the author's suggestion about where the burden of proof should be. And I don't even like Chesterton's Fence, and here I'm having to basically argue for it!)