This can be especially evident amongst beginner programmers, who are learning new techniques almost constantly, but it only seems to become a dangerous anti-pattern if the individual becomes overly fixated on a particular technique.

Interestingly this anti-pattern can apply to more than just individuals, in my experience it can also apply to teams or even entire organisations.  One of the ways I have seen this manifest at a team or organisational level is with attempts to solve social problems with technology solutions.  This trait seems to be especially strong in software development organisations: perhaps because technology is their usual solution to problems.

Such social issues faced by development teams and organisations can include things like not breaking the build, lack of communication or lack of testing.  These problems really are not technology problems, they are social (people) problems, yet time and again I have witnessed technology solutions to these problems.  For example, more elaborate and sophisticated check-in systems being introduced in response to constantly broken builds, where a much simpler social solution such as peer pressure to not break the build would be much more effective.

Avoiding the Golden Hammer when programming is achievable with some self awarness and honesty: are you using your current technique for the right reasons?  However, identifying and interveening when a team or organisation is about to use the Golden Hammer is much more challenging as it can involve going against the solution favoured by the majority along with the polical implications that brings…

This may seem harmless but consider that the future use cases you are imagining are not something you fully understand yet: as most of us will admit we are pretty bad at anticipating the future.  So how can we hope to implement future functionality successfully?  The most likely outcome is that whatever you implement now not be sufficient when you actually try to use it in the future.  This will mean more time will have to be invested in the future to refactor or replace the functionality with what is actually required.

Unless you also plan to implement a full set of tests for this new functionality then you are adding extra code to your program that will not be correct and will not stay correct.  This can also lead to really weird run time behavior if the flow of program execution goes into your new ‘future proof’ functionality unexpectedly: which can be very hard to debug.  Adding functionality for future use without corresponding tests also means that as the rest of your program evolves the future functionality does not evolve with it, this means by the time you actually try to use it that it is most likely hopelessly out of sync with the rest of the code base.

The future functionality is also expanding the size of the source code of your program which leads to unnecessary code bloat.  In some compiled languages (e.g. C++) code bloat will lead to increased memory usage and decreased program performance which is highly undesirable.

Another thing to consider from a business stand point is that you are spending time and money implementing future functionality when you are not being paid for it.  This is a strong indication to me that implementing future functionality makes little business sense.  As it means spending money now paying developers to implement functionality that you can’t sell right now.

There is a handy acronym for this: it is YAGNI which stands for ‘You Aren’t Gonna Need It’.  The essence of this concept is to only implement the functionality you need right now and to implement in as simple and robust a fashion as possible.  As simple robust code (preferable with acompaning unit tests) is code that can be easily refactored in the future to meet future needs and that is cost effcient!