The Continuous Obsolescence Anti-Pattern

As hard it is to spell the Continuous Obsolescence anti-pattern is easy to fall into. The lure of shiny new versions of products often leads us into this trap. We want to stay current with the latest features. However, the cost of keeping up-to-date can put us in a pattern of upgrades over enhancements.

Defining the Continuous Obsolescence Anti-Pattern

The wiki c2 site provides a beautiful, pessimistic view of this particular anti-pattern. [Click Here to See The Page]

"Continuous Obsolescence: This is the hardest Anti-Pattern to overcome. Corporations have their pet system that they mutate every time a new computer language and/or buzz-word builder comes down the pike to the developers. As soon as the pet system is migrated into the new language and/or method it becomes obsolete and thereby cancels any possibility of developers receiving a bonus for bringing the design in on time. It is also used to justify corporate heads existence by moving the blame for a poorly designed system to a new language and/or method of construction."

This paints a depressing picture of this anti-pattern where it is almost intentional in its appearance. I think the definition points more to planned obsolescence than continuous. However, it does provide a synopsis that should make anyone want to avoid it. If you are thinking that it feels a lot like being in quicksand, then you see why this is an anti-pattern.

SAAS - A Silver Bullet?

Software as a service is often the best way to avoid this anti-pattern. The updates will come as frequently as a vendor desires. However, you will have the cost of upgrades carried by the vendor instead of on your team. This is not a perfect solution, but it comes pretty close. Most SAAS vendors find it far too costly to their bottom line to make significant changes that impact the productivity of their customers. While that does not tend to help developers that are using the latest frameworks, it does reduce or remove third-party integration headaches.

Draw a Line In The Sand

While Continuous Obsolescence is almost a given in the fast-moving IT world, there are still ways to avoid it. The best is to define a development environment and freeze it. I have seen this done to the point of downloading the binaries required to do the development. That means there is no need to worry about something being unsupported or hard to find. You select the tools and version when you start implementation. Then you march forward with those resources. Ignore updates as much as possible. This will at least help you stabilize that moving target that a Continuous Obsolescence anti-pattern creates.