I think I can boil it down to one sentence: In quality code, the cost of changing the code grows more slowly than the benefits. Everything else flows from thi

I think I can boil it down to one sentence: In quality code, the cost of changing the code grows more slowly than the benefits. Everything else flows from this: functionality, readability, clean design, appropriate technology to problem, appropriate effort spent on problem, availability of programmers who can work on such a system, management of legacy features, and foresight of problems and opportunities in the future. Lame 10-line bash scripts that even repeat a few lines can be quality code. And so can entire application frameworks coded in C++. The Agile people might say that the cost should instead be proportional. They would argue that if extension of the system is too easy, you probably overspent on the initial quality. But I feel in my bones that this is wrong. We should really be aiming for a polynomial or exponential ratio of benefits to cost.