The fastest, most bug free code is the code that doesn't need to run. The most consistently implemented procedure is the one that doesn't require anyone to do

The fastest, most bug free code is the code that doesn't need to run. The most consistently implemented procedure is the one that doesn't require anyone to do anything. I agree that when looking at a process that seems bloated and inefficient, we should be mindful of the XY problem: https://en.wikipedia.org/wiki/XY_problem https://en.wikipedia.org/wiki/XY_problem In my experience most procedures are created not due to a deep nuance to the problem space that makes procedures superior to automation, but rather one of the following: 1. Leadership lacking the technical background to understand what automation would look like or accomplish. (In extreme cases, this can manifest as people creating processes that are redundant with automation capabilities built into the tools they are already using.) 2. Leadership lacking confidence that the organization has the skills or resources to automate effectively. > Bloaf, it's the employee's job to bring the case for automation to their leadership... 3. People in senior technical roles shooting down automation efforts because a significant amount of their expertise is "expertise in navigating existing processes" and they don't want this expertise to be undermined.