That’s not what I get from the article. The problem does indeed occurs at step 2 and 3: leave duplication alone and don’t introduce abstraction if you are not sure about future requirements.
Taken to its logical conclusion, doesn’t that argument mean we would almost never introduce any abstractions at all? That doesn’t seem very practical compared to the alternative of introducing abstractions if they are useful at the time but remaining willing to change or remove them again later if the situation changes.
Yes my comment was poorly worded it misses something like "unless you have a strong case for it". Also there was a title change on HN, previously it was "Duplication is far cheaper than the wrong abstraction", she also says "prefer duplication over the wrong abstraction" at the beginning, so with that emphasis I might have misinterpreted the rest of the point.
