I disagree with #25. It seems to me that change is a subject to a kind of no-free-lunch, if everything is easy to change in your system, then it doesn't do anyt

I disagree with #25. It seems to me that change is a subject to a kind of no-free-lunch, if everything is easy to change in your system, then it doesn't do anything useful. IMHO you always have to be opinionated and predict what change is more likely and adapt to that. Speaking of change, regarding #1. I am not clear how to reconcile (Agile's?) "embrace change" with the well-known observation that fixing a problem in a SW system seems to be more difficult later in the design-implement-test cycle. Commonly, this is addressed by making that cycle smaller, but it seems to only constrain the design space (large and consistent designs are ruled out). (There is probably a good reason why we don't build buildings using Agile, but we gather requirements first and then build it.) Finally, I would add a rule - Don't change what works.