Those are fair points and I think that the example you use with Dick and Jane is a good one:
Suppose Dick and Jane both implement their simple feature which is fairly similar. I'd estimate that much of the time it's costless to have two slightly different approaches in the codebase. In those cases it's also nearly costless to retroactively standardize.
In the remaining cases where it isn't costless to retroactively standardize, a better optimized abstraction would have been useful. But, depending on the product's life cycle, building that abstraction may or may not count as premature optimization. Suppose Dick's feature takes off but Jane's ends up being phased out, now the extra month building the abstraction was totally wasted.
Is that technical debt a big leveraged call option that could cripple the team/org? Maybe, but maybe not. Maybe it's just a hassle that needs to be borne only if the feature succeeded, and thus would have been premature optimization if the feature didn't succeed. In other words exploration vs exploitation and the risk of cementing possibly unneeded conceptual overhead. I guess my intuition is that premature optimization comes from attempting in advance to pave the way for a low technical debt future on an unknown feature horizon.
It takes real skill to avoid this if one is too attuned to technical debt elimination as a design goal.
Suppose Dick and Jane both implement their simple feature which is fairly similar. I'd estimate that much of the time it's costless to have two slightly different approaches in the codebase. In those cases it's also nearly costless to retroactively standardize.
My experience disagrees on both counts. Furthermore my experience is that if I'm actively developing code and feel that a particular piece of cleanup is a good idea, the usual time to my discovering that it really was a good idea is about 2 weeks. (In maintenance it proves itself much more slowly.)
Of course I have quite a bit of experience and a well-trained intuition. I've seen other people whose "cleanups" were anything but, and who were fond of entering abstractions to simplify the future that would never pay off. (I'm a big believer that making something simple with little code makes virtually any future rewrite easier. This helps. A lot.)
Well, returning to the OP, selling a call short does not automatically mean you lose money. It's just that once in a while you are exposed to losses that far outweigh the price of the call.
So perhaps the Dick and Jane example is one where you are ahead of the game by leaving the code as is and only refactoring it later when needed.
It does take real skill to forecast what is needed and what isn't, we 100% agree on that :-)
Suppose Dick and Jane both implement their simple feature which is fairly similar. I'd estimate that much of the time it's costless to have two slightly different approaches in the codebase. In those cases it's also nearly costless to retroactively standardize.
In the remaining cases where it isn't costless to retroactively standardize, a better optimized abstraction would have been useful. But, depending on the product's life cycle, building that abstraction may or may not count as premature optimization. Suppose Dick's feature takes off but Jane's ends up being phased out, now the extra month building the abstraction was totally wasted.
Is that technical debt a big leveraged call option that could cripple the team/org? Maybe, but maybe not. Maybe it's just a hassle that needs to be borne only if the feature succeeded, and thus would have been premature optimization if the feature didn't succeed. In other words exploration vs exploitation and the risk of cementing possibly unneeded conceptual overhead. I guess my intuition is that premature optimization comes from attempting in advance to pave the way for a low technical debt future on an unknown feature horizon.
It takes real skill to avoid this if one is too attuned to technical debt elimination as a design goal.