| It's funny you chose that principle in particular because it does have an exception listed: https://principles.dev/p/one-single-source-of-truth/ > Exceptions
> Highly distributed systems - Some systems rely on data consistency to be reached eventually or may never need to have accurate data. I've written about exceptions here: https://principles.dev/documentation/#exceptions-optional In general, exceptions should be quite broad and people can add these to the principles if they know of them. They can also have higher priority "contradictory principles" which override the lower priority principles in certain cases. Overlapping of principles create complex behavior so it is usually better to have a list of principles in priority order (this will be covered under emergent behavior in "principle-driven engineering") which can override the "single source of truth" principle. An example might be: Engineers will know they should use single-source of truth, but as performance should be critical (or they have a specific business rule that states something must take less than 5ms) it will override that principle. Does that answer your question or do you think it needs to be more refined than that? I wonder if making the principles editable by the team would be a useful feature, so you'd be able to add your own exceptions to them for your particular use case. |
Being able to stack rank principles is interesting. I think in practice, different principles apply to different use-cases and systems. There may be a certain set of principles for "critical" functionality pieces, but maybe a different set for features like reporting (such as staleness of data).
Amazon's leadership principles aren't specific to engineering, but they keep competing ones with tension between them all the same (e.g., "Bias for Action" vs "Insist on the Highest Standards").