What to do with old software
The older your code gets the more lines of code it accumulates, the more closely coupled modules become and the higher the
effort to maintain and evolve your product. So, what should we do with old software?
● Rewrite it: Just throw it away. When maintenance cost is very high and
the source code doesn’t have any economic value, this is the best
option. Even though this could seem an easy task, duplicate a system
behavior is almost impossible and very expensive for big products, so
this is a hard decision.
● Harvest from it: A piece of software could be old but we can always
learn from it since it may contain solid parts that have been working for
years of real use. Study the software to reuse most of its ideas or
design in a new system is also known as Software Archaeology.
● Wrap it up: The most common problem with old great software is that it
needs to be integrated with newer technologies. So, we can also
consider take that good code, put a wrapper around it and press on.
From the inside the great old code, from the outside ready to be
integrated with modern technologies.
● Transform it: Most of the software will be in this category for most of
their lifecycle. The maintenance cost is not high and product keeps
evolving to provide more business value. The key factor is be able to
keep the software in this stage as long as possible doing a trade off to
control technical debt.
Harvest / Wrap up Transform
Transform and evolve software - Technical debt
Technical debt is metaphor referring to the consequences of
poor software. Like a financial debt, the technical debt incurs
interest payments that come in the form of the extra effort that
we have to do in future maintenance. Often, it’s the result of a
series of good or necessary tradeoff decisions made over time
justified by their immediate ROI or the needs of a project.
We can choose to continue paying the interest, or we can pay
down the principal by refactoring and improving the solution.
In a recent Forrester Research survey of IT leaders at more than 3,700
companies, companies estimated that they spend an average 72% of the
money in their budgets on such keep-the-lights-on functions supporting
ongoing operations and maintenance, while only 28% of the money goes
toward new projects.
How can we do it better??
Transform and evolve software - Technical debt strategy
How does it
Where we are?
Technical debt is assessed in 7 categories
in order to better drive your decisions.
Categories are organized in a pyramid
because it reflects how our efforts should
● in order for a software application to
be able to be easily maintained it has
to be testable, reliable, upgradable,
performing and maintainable.
● To work on Reusability we need a
solid base or we would spread
problems among many applications.
How to deal with this?
The first key milestone is to know where you
stand in terms of your technical debt and set
Modern tools like Sonar allow us to take
instant metrics, assess the economic value of
your technical debt, among others, in order to
compare the money we are investing on each
category and ROI of the reverse technical
There are 2 bigs ways to approach a
payback for Technical Debt:
● a big bang approach that fixes
everything at once (which almost never
is a smart strategy)
● a selective approach to reduce the items
with highest severity in specific
categories. According to your strategic
plan for that application you could
prioritize items in order to achieve your
Are you ready for