Should the maintenance of legacy technology come before the implementation of new technology?
A classic chicken and egg dilemma.
Obviously the legacy technology came first but should the maintenance of legacy technology come before the implementation of new technology?
By its very nature the fast moving pace of technology change means that new technology quickly becomes legacy technology and Technical Debt starts to build. Another factor to consider is that the cost of change increases exponentially with Technical Debt – the longer you leave it the more expensive so the longer you leave it.
You get the picture. Later never happens! (And gets more expensive)
Neglect debt and it grows like a Tetra – a many headed beast – becoming increasingly difficult to control.
At ISC we’ve identified debt beyond the purely technological:
🧩Regulatory Debt: built into the solutions conceived to meet the requirements of Regulatory Change by a project team that doesn’t have to maintain or operate them in BAU.
🧩Product Debt: built into the operating model of a product built by a project team that doesn’t maintain or operate it.
Agile ways of working are one solution - explicitly incorporating maintenance and Debt removal into sprints.
However, you don’t have to be working Agile to resolve debt related issues. Start by acknowledging that it exists and allocate time and resource to contain it - try bringing Run & Change closer together.
It would be great to discuss the Implementing Technology Change | FCA with any Change colleagues – please get in touch to see how @ISCtd can help you with your Change practices.