Who has time to write documentation? As the software evolves, the documentation will need changing. Who has time to write unit tests? As the modules evolve, the unit tests will need updating. Why do any of these things?

A well-written piece of code that actually solves a complex problem is a demanding mistress and doesn't appreciate the "who has time..." attitude.

Among the software engineering good practices that I engage in, I'm finding this to be one of the highest bang-for-the-buck ones.

For example, literate programming is a thing that many people believe is worth the effort, at least in certain scenarios and at least for certain parts of codebases: But, if you can make your codebase more readable without requiring additional prose to be written, then that's a comparatively high bang-for-the-buck alternative.

In practice, linear structure doesn't need all that much updating at all: You may have noticed that I don't use strictly sequential numbers. Early in the life of the codebase, I will generally skip lots of numbers, so that I can fill in the gaps with code that comes later. Mostly, all it really takes is to be intentional about where in the linear order to insert new code.

Also, note that it's still useful, even if no one ever goes on a mission to read the codebase in its entirety. If the codebase as a whole has a linear structure, that also imposes a linear structure on any subset of it. If you have five sourcecode files that are somehow pertinent to something you're doing, you immediately know the order in which to look at them.