I think about defining the "maintainability" of code as a reduction in the amount of time that will be spent working on that code in the future. Therefore, ther

I think about defining the "maintainability" of code as a reduction in the amount of time that will be spent working on that code in the future. Therefore, there are two broad categories of maintainability fixes: 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."