A feature I’m working on right now involves a ridiculous amount of knowledge of the service component architecture and release process because making any change coordinated across two different hot services with different release schedules is absolutely hellacious. So even though customers will barely notice the change, I have to do all this release and flag and migration and analysis work simply because people actually use and depend on our service and we have to be really careful not to break it.
It’s not necessarily a bad thing. If we didn’t have to yak shave, it would mean we either weren’t making money, didn’t care about our customers, or didn’t do anything important. In 2005, maybe most people weren’t working on hot services with complex architectures that people depended on. But imagine what would happen if the tens of thousands of people working on AWS all collectively decided to not shave yaks when they updated their services.
On an individual basis, your decision to not shave a yak might save time and effort. At scale, it increases your error rate. If you have thousands of developers and hundreds of components/services to keep track of, issues are already an inevitability, and you’re increasing the rate at which issues would occur by a lot.