1. To reduce the number of changes that will need to be made to it.
2. To reduce the time it takes to make each change.
The (1) category encompasses the idea of making code that requires few changes. Such code is essentially "right" to begin with. I think about this mostly in terms of models -- i.e. does it accurately model the problem -- and quality -- i.e. does it have bugs or performance issues. Of course there are other concerns as well, but those are two big ones and they often involve thinking like a "computer scientist."
The (2) category -- reducing the effort of changes -- is achieved by using appropriate abstraction layers, encapsulation, low coupling, and other good-program design. There are many technical concerns in this category, but it seems there are some social ones as well.
I would say the programmer's experience is another huge factor. To sum it up in a phrase, perhaps "writing maintainable code is an act of prediction."
Since it's similar to math, it's as clear as it can be. Like functional programming - the cleanest code is one line of code which expresses the intent as an mathematical function.
Maintainable code is more an act of writing than of mathematics.