5 ms·
Good god, no. Do not do that. Because what'll happen is, you'll find out that the type of risk you actually encounter ends up being tied to (say) the time of y
by mkozlows 11y ago
Good god, no. Do not do that.
Because what'll happen is, you'll find out that the type of risk you actually encounter ends up being tied to (say) the time of year in a way that you were not expecting, and now you've got this elaborate risk-plugin architecture sitting there, and there's no way to get the time of year down to the risk calculator, so you need to elaborately hoist out and redesign this entire gigantic apparatus, instead of just adding a parameter to a function call.
And meanwhile, as you were daydreaming your future hypothetical risks and trying to have an idea of what stuff they might need to know, you imagined that it might need to know what currency the thing is priced in to calculate currency-fluctuation risks, and so you're passing currencies all over the place, to be prepared for general extensible etc., but it turns out you never need them in your risk calculators anyway, so it's just this pile of unnecessary nonsense of setting currencies everywhere and you have to maintain all that.
And if you read those paragraphs and think "hmm, you'd probably want to make it extensible in terms of which fields are passed into the risk calculator to prevent that kind of problem" then realize that you are now solving a hypothetical problem that was caused by the "solution" to your first hypothetical problem, and you're three levels removed from delivering any actual value to anyone.
Forget about it. Don't plan for it. Plan for what you need today, because you will not be good at anticipating what you need tomorrow.
- eridius 11y agoYou seem to be dividing the world into two possibilities: 1. Don't plan ahead. Only implement what you need right at this moment. 2. Plan for everything that's even remotely imaginable. #2 is quite ridiculous. But the alternative to that is not #1. There is a huge amount of middle ground here, for assessing likely future needs and designing your architecture appropriately, as well as for identifying what future requirements affect architecture and which ones can be safely ignored as something that can be easily implemented on top of the current architecture. The problem with #1 is this either leads to re-implementing large portions of your app (possibly many times if you persist with this) as you discover your architecture doesn't work; or, more likely, adding hack on top of hack to implement new functionality without having to rearchitect, which leads to massive technical debt and results in an un-maintainable product.
- lowbloodsugar 11y ago3. Do plan ahead. Only implement what you need right at this moment.
- vog 11y agoI believe the YAGNI version of this is: 3. Do plan for replacing any part of the code, but don't try to guess upfront which one it will be.
- unclebucknasty 11y agoBut, what are you defining as "architecture" here? Having a design that requires you to completely re-implement your app whenever changes are required (even significant ones), seems more a problem of not following proven design principles than one of poor "architecture".