Yak shaving is an inevitable, unavoidable part of working in a large company with mature (or rather: conservative and safe) engineering practices.
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.
Software Developers will often be tempted to automate the yak shaving away so they don't really have to deal with it all. This is a good attitude to have, but when combined with automation it can also be dangerous. I've seen many automated solutions run off on their own doing entirely the wrong thing. It's very often safer to slow down, build tools to assist, but have a human there to push the go button. It's not as sexy, and if you're scale is large enough you're also building tools to help with analysis. But in the long run you'll avoid problems.
Comments
Yak shaving is an inevitable, unavoidable part of working in a large company with mature (or rather: conservative and safe) engineering practices.
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.
One thing I'd like to add to this.
Software Developers will often be tempted to automate the yak shaving away so they don't really have to deal with it all. This is a good attitude to have, but when combined with automation it can also be dangerous. I've seen many automated solutions run off on their own doing entirely the wrong thing. It's very often safer to slow down, build tools to assist, but have a human there to push the go button. It's not as sexy, and if you're scale is large enough you're also building tools to help with analysis. But in the long run you'll avoid problems.
Yep. Sometimes it’s time to shut up and give that Yak and good hard shaving.