3 ms·
The argument behind premature optimization only really stands when first developing a product. Once you have an established product, it's no longer premature,
by ownagefool 12y ago
The argument behind premature optimization only really stands when first developing a product. Once you have an established product, it's no longer premature, it's just optimization.
- emodendroket 12y agoWell, only if you never add any new features to it.
- wvenable 12y agoAs long as you are not optimizing those new features as you are adding them, it's not premature optimization.
- Scuds 12y agoWith 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!
- equoid 12y agoPremature 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.
- dragonwriter 12y ago> 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.
- steve-howard 12y agoI'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.