Decommissioning

Quote on this page: there is always a business case behind Decommissioning.

I am still wondering why in case of replacement of functionality that decommission is not part of the project.

Project ends, cost of the old system/environment still goes on.

How does their home looks like? Plenty of old cars in front of the house, still paying tax and insurance on these cars?

My experience with Decommissioning


My mindset: I don't want to spend time and money on any Hardware, Operating Systems, Subsystems, Applications, or application code what is not supported and/or not used.


More important than the waste of time and money: it is a big risk in reliability of your IT environment to the business.


There is a relation between dead code and incidents and there a relation between pace of change and dead code.


On the right side of this page you will see true examples.

If you don't have an active Life Cycle Management in place, if you don't have a active decommissioning culture and structure in place: YOUR COMPANY IS AT RISK for business continuity.

Life Cycle Management mindset


During my De Telegraaf time I was responsible for the Datacentre and Life Cycle Management. For sure, I never ever have running any stuff what was not supported of out of date. The mindset of Life Cycle Management was that at least 1 year, if possible 1,5 year before support would be expire we started the questioning:

  1. Vendor will the support be extended?

if not:

  1. What will be the upgrade? and when this upgrade will be available?
  2. can we or could we replace this with another product?
  3. Can we arrange another functionality so we can decommission this functionality?

There are several sample I have seen.

I will mention a few of them.


  • In this century I have seen several applications what still supported TELEX
  • You have to explain people younger than 40 years what TELEX did in the past, and what it looks like, please explain also paper tape.
  • I have seen an application with more than 80% dead code.
  • I have seen incidents that takes a long time to resolve this because somewhere the latest change it used TELEX protocol support.
  • I know, that today, several companies are still using Windows XP on mission critical applications.
  • I have seen a company using Databases on mission critical environments what was not on support... for many years.
  • BTW because you use this (not supported) Database you still have to pay your license and maintenance fee. It is your decision not to upgrade. A splendid example of risk and waste of money.
  • I have seen a company using mission critical applications with a limited support by the vendor ( we maybe can provide you a work around).
  • Combine a not supported Database with dead code and 1970 way of programming (memory cost money) and you know where your RISK is and your money flows.

2nd quote: develop new functionality: spend 30% of your time on testing. Decommissioning of old functionality or dead code: spend 50-70% of your time on testing... End to End testing. Please.

It is not easy to convince the business to

spend money on decommissioning.


It is hard to convince the business to spend money/budget and they will not receive new functionality. The good news is: Yes you can, but with the good explanation and good samples.


Remember that in an environment with dead code, you have to take care of that dead code (read spend time/money on that) on every change request:

  • Analyzing phase (what if this change, or could this change interfere with the old/dead code)
  • Development phase (work around the dead code, never a what if then else code what could bring you in de dead area)
  • test phase (testing if you are will not use the dead code. including special testcases to create evidence that you are not using the dead code)
  • Production (I have seen incidents because dead code what was used) 


It is very in-efficient and create a degradation of your pace of change if you have dead code around.

I have seen my very best Developers having big issues because of complexity working around dead code. At one time I have seen Developers pump the break that it was almost impossible to change this application because dead code. I have seen very complex incidents because of dead code.


It was the Business who gave the budget for dead code Decommissioning. It was the Business who confirmed afterwards it was a very good to spend time and money on this, because after this clean-up the code the pace of change was 20-30% faster.


3rd Quote on this page: Life Cycle Management and Decommissioning are brothers and sisters.

They love each other. And there are no fights between them.

RIEKELT PASTERKAMP



Management Drives: Oranje / Geel

Copyright @ All Rights Reserved