As these reasons might provide a useful insight into why patterns die or become outdated, they also provide many ideas and clues about the critical question: why have not patterns fulfilled the expectation of playing a crucial role in software development?
Even though many of us think of a pattern as a possible solution to a problem, it may or may not really work for every problem, and hence, it is up to the discretion of the developer to either use it or just develop a customized solution. If patterns can die, then is there a risk in heavily utilizing them during development? One obvious and short answer is yes, the patterns may become a legacy system, and developer must deal with upgrading, modifying, or enhancing that system, given that the replacement of the entire system is both costly and time consuming.
Returning to the three reasons cited above, that might cause a pattern to die or become outdated, they can be rephrased to answer the question of, why patterns are not as effective as developers may have envisioned during the earlier phases of development.
We can rewrite these reasons as follows: patterns are not as effective as they should be, because they do not present the best possible solution to the problem at hand and there is always a better solution than what the pattern proposes in real. So, what causes a solution to a specific problem be classified as a bad solution, or why can a better solution to the same problem evolve?
If patterns are technology inter-dependent, then the frequency of changes in the technology will drive the frequency of changes in the pattern’s usage as well. Consequently, rapid changes in technology will render these solutions obsolete and outdated, even before they get the chance to become accepted. This obviously contradicts the original goal of patterns as reusable artifacts.