Description

The more legacy code your team maintains, the greater the impact on their productivity. Legacy code is a tax, and should be deleted when possible.

Notes:

• Organisations often approach legacy applications with a sense of fear.
• Throughout my career, I have seen legacy applications, or legacy sub-systems of an application that contain some code that nobody left in the organisation understands.
• I have even seen Cobol applications running on mainframes for 20-30 years, that are well beyond End-Of-Life (EOL), and yet somehow they still "just work" and nobody wants to switch them off.
• You should delete that code.
• The reasons for this are simple:
  1. Legacy code is a tax. You need to pay to maintain it, and pay an opportunity cost for any resources or thought you need to waste on it.
  2. Code that exists in your team that nobody is willing to work on is literally unmaintainable.
  3. Tech that stands still in time is dead tech. It is your job to kill it.
  4. Less is more. The smaller the code base your team needs to maintain, the more efficient they will be due to less legacy tax.
• If we take the approach of "commit or cancel", we should either fully commit to maintaining an application in production, or cancel it. There should be no halfway, somewhat working, somewhat broken state.
• One useful approach that a team can take to deal with legacy applications is the Strangler Pattern, which is defined as follows on the Redhat site:
  "The Strangler pattern is one in which an “old” system is put behind an intermediary facade. Then, over time external replacement services for the old system are added behind the facade.
  The facade represents the functional entry points to the existing system. Calls to the old system pass through the facade. Behind the scenes, services within the old system are refactored into a new set of services. Once a new service is operational, the intermediary facade is modified to route calls that used to go to the service on the old system to the new service. Eventually, the services in the old system get "strangled" in favour of the new services.".
  Ref: https://www.redhat.com/architect/pros-and-cons-strangler-architecture-pattern
• That pattern can help settle nerves, by enabling the organisation to run in parallel the legacy application and the new service that will replace it over time.
  All legacy applications or sub-systems should have a modernisation plan ("commit") or a decommission plan ("cancel").
• Just leaving the lights on is never enough: hope is not a strategy.
• What I am working on this week:
  • New blog "Decline is a step down process" - https://techleader.pro/a/619-Decline-is-a-step-down-process
  • New video formats on Youtube: more visual thanks to stock photos and videos.
• Media I am enjoying this week:
  • Diaspora by Greg Egan.
  • Caesar by Christian Meier.

Notes and subscription links are here: https://techleader.pro/a/620-Tech-Leader-Pro-podcast-2023-week-42,-delete-your-code