You write chapter 1. This is math, you've laid out several definitions, theorems, propositions. You write chapters 2-5. You get to 5 and you realize your choice of terms was poor. Or that you only define some term in chapter 5.
You realize that definition should be before chapter 5, but in which chapter? 1, 2, 3, or 4?
You have to review each chapter (probably in reverse order) to determine the latest position it should be in.
Additionally, as you add that definition you find out that there's even more that needs to be shifted. Do you reorganize the whole thing, or leave it as is? You'll end up spending as much time reworking the text as you did writing the original.
===
Really, this is a philosophical thing. In the spiral approach you end up reviewing things early and realizing what's missing and where they should be moved. In your approach, you don't get to do the review until late. Is it wrong? No. But it can create a less flexible document that requires more effort (and not less) to correct.
This is very similar to the argument in lean software development of keeping batch sizes low (small number of changes at a time) but running them more frequently. Versus the waterfall approach which has large batch sizes and takes much longer to do it all, with a big review near the end.
You realize that definition should be before chapter 5, but in which chapter? 1, 2, 3, or 4?
You have to review each chapter (probably in reverse order) to determine the latest position it should be in.
Additionally, as you add that definition you find out that there's even more that needs to be shifted. Do you reorganize the whole thing, or leave it as is? You'll end up spending as much time reworking the text as you did writing the original.
===
Really, this is a philosophical thing. In the spiral approach you end up reviewing things early and realizing what's missing and where they should be moved. In your approach, you don't get to do the review until late. Is it wrong? No. But it can create a less flexible document that requires more effort (and not less) to correct.
This is very similar to the argument in lean software development of keeping batch sizes low (small number of changes at a time) but running them more frequently. Versus the waterfall approach which has large batch sizes and takes much longer to do it all, with a big review near the end.