Premature optimization is that which is done before the need for the optimization is clear. Thus debugged, feature complete (for now) ... 'Established' really has nothing to do with it, if that established product has bugs then those should be addressed before attempting to optimize. Unless of course, the lack of optimization is itself the bug.

> Once you have an established product, it's no longer premature, it's just optimization.

Its premature even if the product is completely feature complete and bug-free if the particular optimization being done is being done before more significant optimizations, which, if you aren't using some measurement more sophisticated than "this looks like it could be optimized" to choose what to optimize, it probably is.

I'm late to the discussion, but I will say that when you have an established product you have a much better perspective on how the code is organized than when you're still cobbling together V1.0. A firm grasp of the code's organization makes it much easier to contain the optimized part and slap on a /* HERE BE DRAGONS */ header.

Well, only if you never add any new features to it.

As long as you are not optimizing those new features as you are adding them, it's not premature optimization.

With a full suite of automated regression tests you'll have a great deal of confidence that any changes you've made didn't break anything. Go nuts and experiment!