> if your system is dependent on laws, then you can be sure that new rules will need to be added. You need a system that is configurable, you can be sure you are going to need it.
This doesn’t violate YAGNI.
1. You’d have to know in advance what the scope of rule changes would be in order to implement the configuration system.
Human laws do not fit this constraint.
2. You’d also need a way to prove that the configuration system itself was sound.
3. You’d need a way to test configurations to make sure they executed as expected.
That is likely to be no better than just updating the codebase as requirements change, and there are many ways it could increase the cost.
1. Yes. A subset of human legal history would give you that information. You could argue they did that, just chose the wrong subset.
From a planning perspective though, it isn't the rule changes that are the problem; it's the types of input. For example, if you write a system that says "Given X class of crime, and they were convicted in year Y, and Z much time already incarcerated, return f(X, Y, Z) days left". If you can build all your rules around that, that's great.
If you then say "Oh, but for crimes a, b and d, we need to take into account some measure of inmate behaviour" - you now need to incorporate a whole new path from that data point to your decider, and all these functions need to accept this information and either use it or discard it - and that might take some time. (I should insert a discussion about monads as a design pattern that would simplify this code and remove this excuse... but we'll assume ignorance of that for now)
So the question is whether this is some new datapoint that they should have already expected. Maybe it wasn't - but if that's the case, then they definitely looked at the wrong subset of legal history.
2. and 3. are moot points in my opinion. Your configuration system is the basis for all your existing rules. They already have multiple rules, so they have a baseline for saying that the configuration system is sound. If your configuration system fails to properly account for unused datapoints, then fine. But as I mention elsewhere, configurability doesn't necessarily mean end-user configurability. A well-written system should not be resistant to change.
This doesn’t violate YAGNI.
1. You’d have to know in advance what the scope of rule changes would be in order to implement the configuration system.
Human laws do not fit this constraint.
2. You’d also need a way to prove that the configuration system itself was sound.
3. You’d need a way to test configurations to make sure they executed as expected.
That is likely to be no better than just updating the codebase as requirements change, and there are many ways it could increase the cost.