> How much ongoing effort should be put into handling the possibility that this particular requirement might change?
How likely is it that the world freezes and stops changing around your software? This includes business processes, dependencies, end-user expectations, regulations, etc.
In general that’s the difference between a product and a project. Even Coca Cola keeps tweaking its recipe based on ingredient availability, changes in manufacturing, price optimizations, logistics developments, etc.
Hell, COBOL and FORTRAN still get regular updates every few years! Because the software that runs on them continues to stay under active maintenance and has evolving needs.
As a general rule, one should presume that they now less about running a business than the people that actually do that. There are exceptions but as with all rules, exceptions don't invalidate the rule.
"they should stop" is a fine rant to express your personal taste preferences, but objectively speaking, I would bet on Coca-Cola having good reasons when tweaking the recipes. If that happens, it's probably more necessary than a layman realizes.
Yes and no. We’ll never know. There are small changes all the time. You and I wouldn’t even notice the difference.
But if you compared today’s flavor to the flavor of 100 years ago side-by-side, I bet it’s pretty noticeable. Today they use corn syrup instead of sugar, for example. Many of the flavoring ingredients from back then aren’t even legal for human consumption anymore either.
Exact ingredients also differ between markets so we’re not even all talking about the same coca cola.
A part time bar owner I worked with claimed Mexican Coca Cola was the best due the sugar being made out of either corn or sugar cane, I don't remember which one, compared the US one.
It would have been interesting to do a blind test if that.
The result of Agile (and DDD, TDD etc.) comes back to The Mythical Man Month: you're gonna throw one away. So plan the system for change.
And due to Conway's law: plan the organization for change.
From those ideas you derive Agile (make an organization easily changeable) and the tactical part of DDD (all the code architecture meant to be often and easily refactored).
At some point this philosophy has to result in something concrete.
How much ongoing effort should be put into handling the possibility that this particular requirement might change?