I feel like Wayne is taking the Agile Maxim “requirements always change” too literally. Agile doesn’t mean "every requirement always changes forever”.
In most live production environments today, requirements do keep changing — security, compliance, customer behavior, scaling — even when teams think they're done.
Agile isn’t making an empirical prediction ("all requirements will mutate endlessly"); it’s a philosophical posture toward uncertainty
I agree with Wayne that the needs of the user don’t seem to end, even if your project or contract completes. Either the need is to keep maintaining it, put a twist on it, radically change it, or abandon it for something else.
I don’t agree on testing. It’s been a long time since I bought into that, and even tests for uncertain behavior to have confidence is a form of tech debt, as the developer that follows you must make a decision whether to maintain the test or to delete it; its value doesn’t usually last. An exception would be verifying expected behavior of a library or service that must stay consistent, but that is not the job of most developers.
It seems the article is much wiser than this comment. It is a distinction without a difference whether 'requirements always change' or whether 'every requirement always changes forever'. If you don't know which requirement is going to change next week, it does not matter which of these two are true.
That’s fair from a practical design perspective. But, if you treat “requirements always change” as a hard truth rather than a heuristic or philosophical posture, you can end up in a mode where stability is viewed with suspicion, and architecture never settles. Some requirements do stabilize and knowing when that happens can help determine tradeoffs.
> 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).
In most live production environments today, requirements do keep changing — security, compliance, customer behavior, scaling — even when teams think they're done.
Agile isn’t making an empirical prediction ("all requirements will mutate endlessly"); it’s a philosophical posture toward uncertainty
Wayne misses this interpretative nuance.