Amazon is a gigantic series of 2-pizza-teams and fiefdoms. They don't talk to each other much. Just because you "work at Amazon" does not mean you have ever serviced a single customer, or gleaned the experience of the tens of thousands of engineers working there (most of whom don't know the others exist).
But even so, let's assume this person has worked directly with customers, and knows how to design for the real world. Why might someone whose job is not being a practitioner, maybe not come up with the best design?
Take for example the product "Terraform", by HashiCorp. It has severe design flaws which anyone who has been forced to use it at scale will find immediately. But the person who invented it, and its subsequent developers, follow a "philosophy" that has nothing to do with working with it in the real world. It was not created by practitioners, for practitioners, but by idealists, for a corporation to ensnare hapless clients that have sadly adopted their freeware and now need to pay for add-on software to manage it. The end result? It sucks balls.
For an Amazon-centric example, take Terraform's competitor, CloudFormation. It's even more horrible. You write your configuration in a data serialization format, in verbose and clunky huge chunks, and (afaik) can't validate or test them without applying them in the cloud. There's no modules or extensions, and it doesn't really change or improve. It's like someone decided to only build the guts of a configuration management engine and told all the users to just figure out for themselves how to use it. You still need to build a whole 'nother software project just to interface with it in a sane way.
Back to the topic: Many other policy languages and tools already exist, many of them open-source. They could have simply adapted those existing solutions and extended them to include whatever novel, genius ideas they had that those other solutions didn't have. But they didn't. Why? I have no idea. But I'm betting it's not because they couldn't write patches for the other tool.
But even so, let's assume this person has worked directly with customers, and knows how to design for the real world. Why might someone whose job is not being a practitioner, maybe not come up with the best design?
Take for example the product "Terraform", by HashiCorp. It has severe design flaws which anyone who has been forced to use it at scale will find immediately. But the person who invented it, and its subsequent developers, follow a "philosophy" that has nothing to do with working with it in the real world. It was not created by practitioners, for practitioners, but by idealists, for a corporation to ensnare hapless clients that have sadly adopted their freeware and now need to pay for add-on software to manage it. The end result? It sucks balls.
For an Amazon-centric example, take Terraform's competitor, CloudFormation. It's even more horrible. You write your configuration in a data serialization format, in verbose and clunky huge chunks, and (afaik) can't validate or test them without applying them in the cloud. There's no modules or extensions, and it doesn't really change or improve. It's like someone decided to only build the guts of a configuration management engine and told all the users to just figure out for themselves how to use it. You still need to build a whole 'nother software project just to interface with it in a sane way.
Back to the topic: Many other policy languages and tools already exist, many of them open-source. They could have simply adapted those existing solutions and extended them to include whatever novel, genius ideas they had that those other solutions didn't have. But they didn't. Why? I have no idea. But I'm betting it's not because they couldn't write patches for the other tool.