The author of this coins a new phrase — Premature Flexibilization:
…the practice of adding complexity to your code to make it more “flexible”, in anticipation of future change.
The article, triggered an “yes” response in me 🙂 because I felt the same way many times.
In all my coding, I find that I waste a lot of time doing exactly what the author of that article calls “premature flexibilization” — trying to make code as generic as possible, trying to cover many cases that are currently not present, trying to cover all kinds of input. Though it is a good habit, I find that it contributes negatively to project completion and most times, all the genericity, etc was really not used. I have found that it is better to follow the agile practice of YAGNI and code to the current exact requirement and later go back to refactor code when another requirement for the same code comes it to make the code flexible and generic to cover the original and new cases. That way the code goes organically, does exactly what is required and the project gets completed.
One thing though is that it requires some discipline when revisiting the code the second time around to make sure that you test the original requirement is still being met.
I think one of the reasons for the effort spent in making the original code flexible is so that I don’t have to revisit code (mentally for me code maintenance is possibly one of the hardest thing to do).