It's the problem with silver bullets like YAGNI: Laws change, 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.
Of course, if there's money to be made in having a change-resistant system, well that's a different story. YAGNIAYWPTTNFI (You ARE gonna need it, and you will pay through the nose for it) isn't quite as catchy though
YAGNI just means that you don’t know how the laws are going to change. All the configurability you add is just going to make the system more expensive and even harder to change the day when the laws are changed, and it wasn’t anything you thought of. And no one is ever using all your nice switches.
Yes and no. It's a bit like saying "Oh, I didn't know it was going to rain - it was lovely and sunny outside when I wrote the code".
A big (some might say forgotten) part of the procurement and development process is research - know your customer, know your market, know your niche.
In this case, that includes
- know how prisons work
- know how the system will be administered
- know how recent law changes might be handled by the system
- know how often prisoners need / deserve workarounds
- know how quickly law changes need to be reflected in code
Also, I'm not saying that the user interface needs to contain this. But we should always advocate for modular systems that are easy to maintain through addition, rather than through re-writes.
If it is genuinely difficult to add a new type of inmate release schedule, then that is poor planning.
But again, I'm not necessarily subscribing to that theory. Money is involved, so facts are in the eye of the sales team.
No, of course you have to take into account known factors, like sometimes it rains. And if it is difficult to add a new type of release schedule, it is not poor planning, it is a poorly designed system. When we don't know how requirements are going to change, we must not guess, we should instead design the systems so they are easy to change.
> 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.
You'd need a configuration system that is so general it would become a programming language. And then nobody could configure it except the original programmers because now your rules are written in the weird badly-designed programming language you developed.
Of course, if there's money to be made in having a change-resistant system, well that's a different story. YAGNIAYWPTTNFI (You ARE gonna need it, and you will pay through the nose for it) isn't quite as catchy though