Yep, you can't know in advance what code will evolve. I see that as an argument for my position, though. It's faster to write less-readable code. Documenting

Yep, you can't know in advance what code will evolve. I see that as an argument for my position, though. It's faster to write less-readable code. Documenting all your abstractions takes time, as does making sure all your names are ideal, as does making the abstractions in the first place (and they're often the wrong ones if you do them up front). A business only has so much money to spend on a tool or product, and they want maximal bang for their buck. That comes from shipping stuff fast and seeing what sticks. Once you've seen what features are evolving and matter to users, those are the ones you start refactoring and improving, both for functionality and readability. Obviously, do what you can to make your first pass readable. Don't spend lots of time on it until you have evidence this code will be modified often, though, because on average it isn't. I kind of hate this conclusion, and I'm not very good at it, but that's where I've landed these days.