Yes.
Again, based on the past few principles; I think I'll be in agreement with the book.
This is largely recognized as emergent design; thin vertical slices; tracer bullet; walking skeleton... lots of names witih slight variations in their emphasis.
All of these are about producing something that is fully functional and can produce information/feedback to be used to improve that functionality and inform future work.
It's not even MVP; it's build A THIN VERTICAL SLICE - then do it again. If you have a CRUD interface. You have a 4 functions - Create, Display, Update, Delete.
Pick one and do that end to end. Since Update and Delete both need things to exist, you have to start with Create or Display first. I normally do Display. How you create (inline vs modal) can depend on how you display. Display A record.
It's a thin vertical slice.
Display all records. An itteration.
Page the records. An improvement.
Update a single field in the record. MORE FUNCTIONALITY!!!
Another field.
Another.
..
Just do each of these tiny little pieces. They all provide value, but you learn and can apply that feedback into the next thin vertical slice. Especially around the update example above. What if the assumptions of how to update a field is wrong? You'll have written the code for every field... then have to go change every one? Booo - Lots of wasted work. Do one, make sure it works.
OK - What's the book say...
Mostly the same.
What I don't like, and is reflected in early principles
If an inappropriate architecure is selected early, a complete redesign may be necessary to accomodate later changes
Yeah... Nothing stops that. If you use evolutionary architecture; it assumes you'll constantly shuffle around the architecture of the system. Redesign is intentionally part of the flow of work.
Throwing away code because something doesn't easily fit means you'll have to constantly re-design the entire system, ALL THE TIME. That's ... almost dumb. The way it's being presented is dumb. It's being presented as a Big Design Up Front type of redesign. WHich is bad.
We do want to redesign the entire system all the time - While we're working in it. Add a feature; refactor what it touches. Refactor what those touch. Refactor anything that needs refactoring.
Baseds on a twitter discussion; "Refactoring" may not have quite existed as a concept in the industry yet. "Modify existing code" sure... but the level of refactor as we now understand it - Doesn't seem like it. I don't think the industry still gets it; but it is at least a concept known to the crafters.
Someone writing a "Software Development Principles" book today that doesn't include refactoring - They are fundamentally wrong. This book seems to be written at a time (and damn it wasn't really that long ago) where the idea wasn't refined enough to make it into a "how to build software" book.
I won't forgive the book for being so rough here. If you don't know how to refactor; you don't really know how to produce a good product.