In the past weeks I came across the same phenomenon twice in the context of code reuse, which violated Fact 19 from Facts and Fallacies of Software Engineering, which is (to refresh your memory):
Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more effecient and effective to rewrite it from scratch.
I decided to give these unfortunate code reuse occurences, caused by overestimating the similarity of problems and overestimating the benefits of the reuse, a name. From now on we will refer to it as:
Thai•Code•Reuse |aka same same but different reuse|
- An attempt at code reuse without sufficiently understanding the existing code nor the problem at hand, resulting in botched up logic that tries to support both the old and the new solution.
- Reusing code but having to scatter IF statements throughout in an epic struggle to avoid code duplication, resulting in an unnatural solution that is harder to maintain than two distinct components.
ORIGIN The fallacy of reuse caused by an overestimation of the opportunity and value of code reuse.
Spare Time Code 