I think this kind of thinking can easily be scaled also to more abstract parts of projects than the code and infrastructure itself. A core part of the design process of any app is to decide what it will and what it won't do, and these kinds of decisions also involve how easily the decision can be reversed. For example, if one needs to change Twitter to allow arbitrary message lengths, that would probably be completely trivial, if done ahead of time, but since it is part of the core of what Twitter is, the message length limit is probably assumed in a lot of places in the code.
I think the most difficult decisions to make in a project is what to make reversible and what to make easily changable. Abstraction often carries a cost, performance wise or otherwise.
I think the most difficult decisions to make in a project is what to make reversible and what to make easily changable. Abstraction often carries a cost, performance wise or otherwise.