[bilalq]

It'd be cool if counter-points to a principle could also be documented alongside it. Reasoning that highlights why you may not want to adopt a principle is helpful when considering it.

For example, take "One single source of truth".

>Data should be held in one location, duplicates of that data should be by reference only.

>Why

>Changes to data are always propagated to the rest of the system.

>Mutations to the data need only happen in one place.

>Single source of truth means no data will be out of sync or fail to be updated.

>How

>Only allow data writes to happen in one location. Whether that be a call to a rest API, system call or other write actions.

>Don't allow data to be stored anywhere but the single source of truth.

That won't work in many situations. If you need to support high throughput OLTP use-cases but also want to support advanced filtering/sorting of large datasets, you may need something like a combination of a NoSQL DB with something like ElasticSearch. Eventual consistency is something you accept as a trade-off for enabling higher levels of performance.

[AdamCraven]

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.

[bilalq]

Haha, that's an interesting coincidence. I initially clicked into a few that didn't have exceptions listed and just picked that one when writing my comment. I just copied/pasted the beginning and didn't expect the extra section there.

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").

[AdamCraven]

It's the main feature that's missing from this - I'm working on it - context sensitive principle lists, with ranking, which can slice up reality in the way you've said.

Going to be a hard one to get right, so I'm taking my with that one.