I think it's fair to talk about optimisation (premature or otherwise) for anything fitting Blum's axioms. The classic ones are number of instructions executed,

I think it's fair to talk about optimisation (premature or otherwise) for anything fitting Blum's axioms. The classic ones are number of instructions executed, wall-clock time, memory usage, network requests, user interactions, calls to some slow function (e.g. the comparison function, for sorting algorithms), etc. but I think it's also applicable to fuzzier concepts. For example, modularity could be modelled as the time/edit-distance/etc. it would take to swap-out N out of C components, where C >> N. If we're defining things centrally and passing them around via dependency-injection then it's O(N) (each component is defined once, so change N of them); if we're hard-coding references everywhere then it's O(N*C) since we'll have to check for references in all of the components, and each one needs to be checked for the N possible swaps. On the other hand, dependency injection is less optimal than hard-coding for a metric like API size: for N components, the number of references grows as O(N^2) (since new components need to reference existing ones, and existing ones will need to reference them); so APIs using DI will have O(N^2) arguments.