Yep.
Change happens. We NEVER know everything up front. Even if we THINK we do - Things change over time. The priorities change over time. UX Changes over time. Everything is open for change. Trying to pretend otherwise is to reject the reality of the world.
We have to prepare for this. My honest answer is "Refactor". This book is clearly not aware of this practice, so....
Practice RUTHLES REFACTORING while in your software. That's how you handle change.
Let's see what the book says.
...
Make sure documentation is kept up to date.
Procedures for change exist.
Have enough buffer in the budget (or else you might not do the change).
I understand not all software development is about writing code... This is ... dumb.
I'm in a different time; We've advanced. Even this - Refactoring the code enables us to make changes.
None of these enable us to implement the change. Without being able to quickly and confidently make changes, changes will drag the system. This is why there was fear to change - It took so much time.
Refactor. Refactor. Refactor EVEN MORE. Refactoring is a skill, if you don't have it, you will always be slow making changes to the software during it's life.
Change is easy when change is easy. Most developers don't know how to make changes and are in code that is not easy to change - Yeah... takes a long time to get changes in. Done in such a way that it takes even longer to make the next change.
I don't like how the book presents it. It doesn't actually DO anything to help deal with the inevitable change. Principles should give us a guide to make a change. This doesn't.