[Un]Planned Obsolescence in Software

Every time I walk to the 8th Light office from Union Station, I end up looking at Old Chicago Main Post Office in awe. Originally built in 1921, it's a fantastic sight to behold as it sits atop Congress Parkway. Don't just take my word for it, though. This building is so iconic that it was used in the filming of "The Dark Knight," "Transformers: Dark of the Moon," and other movies. More than anything, though, I like the fact that this enormous structure has stood for nearly a hundred years even though it's been vacant for the last 18.

In general, it seems our society has an appreciation for things that can stand the test of time. Interestingly, though, the way many things are constructed in our modern age pales in comparison to the things that were crafted generations ago. If you've ever compared the quality of a piece of furniture in the store now to one that was made 50 years ago, you know exactly what I'm talking about. This has caused me to wonder—If the software industry was as prominent a hundred years ago as it is today, how would the durability and quality of our code compare?

Enter Planned Obsolescence

In 1932, Bernard London, an American economist, wrote a paper in which he presents a solution to the Great Depression. In this paper, Ending the Depression Through Planned Obsolescence, he observed that people had a sub-standard quality of living while granaries and warehouses had great surpluses. This had the effect of stifling production and, thus, perpetuating unemployment. As a result, London proposed that a span of life be given to products, and after that they be retired and considered obsolete.

In the years since, it's become plain to see that the idea of planned obsolescence has been used, and, quite frankly, abused. But, even moreso, the notion of this ideal has permeated our culture and modes of thinking. So much so, that to build something enduring will require thoughts and processes that go against the grain of what is typical or currently most popular.

So, where does software fit in?

It's no secret that there are enormous pressures and demands placed on software professionals. Many software teams have to move at a very rapid pace to keep up with demands from every angle. For the software professional, the product is not a widget or any other commoditized good that can sit and rot in a warehouse. It is, instead, a software application that can, in and of itself, remain useful for an indefinite period of time. If you doubt the validity of that last statement, consider the fact that, as of last year, there were 200 times more COBOL transactions in the world than Google searches. However, many applications nowadays are built with such short-sightedness that many in production today cannot even upgrade to newer versions of the web frameworks that they are using.

This is a problem for business. This is a problem for the advancement of the software industry.

Has planned obsolescence infiltrated our thoughts without us knowing it? Has it become so much of the norm that we don't think much about it?

It's time for us to unplan planned obsolescence in our software.

But, how do we do this?

  1. Identify how long you expect your application to be used. Before reading on, come up with a number.

  2. Recognize that number 1 was a trick. If you decided on any particular number, you've already planned for your application to become obsolete.

The reality is that the most sure strategy that will help developers manage your application 50 years from now is a well-tested application. The test suite is the foundation that your application will rest upon for years and years to come. This is because it promotes consistent planning and design as well as correctness. The stronger that foundation is, the more able you'll be to respond to the changes that your application will need to make in both the near and distant future.

But, if your application is going to become obsolete anyway, of course there's no need for it to be well-tested.

I leave you with this quote from the book Built to Last, by Jim Collins and Jerry I. Porras:

"Indeed, if there is any one "secret" to an enduring great company, it is the ability to manage continuity and change—a discipline that must be consciously practiced, even by the most visionary of companies."

Now, let's put that into this context...

Indeed, if there is any one "secret" to an enduring great [software application], it is the ability to manage continuity and change—a discipline that must be consciously practiced, even by the most visionary of [software developers].

...and let it sink in.

  1. Ending the Depression Through Planned Obsolescence by Bernard London
  2. Built To Last: Successful Habits of Visionary Companies by Jim Collins and Jerry I. Porras
Malcolm Newsome, Software Craftsman

Malcolm Newsome enjoys life and can frequently be found wearing NIU Huskies attire.

Interested in 8th Light's services? Let's talk.

Contact Us