http://www.phparch.com \ August 2019 \ 15How to Deal With Legacy Codethe project which operates and earns
money. After a few years, when there
is a need for changes, it may turn out
there is no one to make them. For
example, the technology may already
be outdated, and there are no specialists.
It might be that a team has an autocratic
leader/architect who knows better and
their authority makes others afraid
to say something that would make
them defensive (although constructive
criticism and discussions are needed
after all). Sometimes we add new func-
tionalities, without thinking about
maintaining it later—it is important
here and now, and someone else will
maintain it.
Finally, we come to the subject
of technological debt. If we make it
consciously, we know why and if imme-
diately we schedule the repayment, that
is fine. However, often we are not even
aware we’re incurring such debt.
I came across a helpful diagram
(Figure 1) showing how legacy code
very often arises as a result of a vicious
circle. We work in a stressful situation
because we must make our deadlines.
This pressure leads to using shortcuts,
with the promise that one day we can
improve it. As a result, we omit good
practices and lower the quality of the
code created. In the end, errors are
discovered late, we extinguish fires, and
this generates additional stress.
Legacy Is Not Your Enemy
The first and natural reaction to the
sight of legacy code is “Who messed
you up like that?” perhaps with more
colorful language. We immediately
assume the code is not suitable for
anything, the person who wrote it didn’t
know what they were doing, and that
we could do it a lot better. Alternatively,
you might think: I’m too good to work
with such code, maybe it’s time to look
for another job? Perhaps this situation
sounds familiar to you because many
people react this way.
It’s important to realize that legacy
code is not your enemy. In fact, we
are here thanks to legacy applications.
Startups can afford to quickly writelow-quality code until the business
starts to make some money. In the
best case, there won’t be much code, it
should be quite easy to rewrite it, and
later we may gain customers, build our
brand, and more. The code may not be
beautiful, but it works, and someone is
ready to pay for it. Thanks to this, we
have the opportunity to work with such
code.
Let’s try to put ourselves in the place
of the original developer. Legacy code
is often old code. Do you think, the
original authors knew as much as we do
today when creating this code? Did they
know the good practices that slowly
emerged over the years as the commu-
nity grew or the language advanced?
When you look at old code, you
think: “It could have been done better.
I would have done it much better.” You
think you’re better and you believe you
wouldn’t write something like that if
you only had a chance. Maybe that’s
how it would happen. Except that when
you start writing your implementation,
you recognize all the limitations that
existed before and maybe still apply.
Only then do you see all the extreme
cases, business rules, and requirements
that are not obvious and that you
couldn’t predict—just like the authors
of the legacy code.
It’s not like some fool who had no idea
about programming wrote it. Legacy
codebases grow in layers over time; we
add new bug fixes and new features
all the time. Sometimes, different
people—who may not even know each
other—implement them. The first
version may have made sense, but it
wasn’t very clear. Another developer
understood it differently and added a
fix that didn’t quite work with the rest of
the code. Let’s repeat it a few times, and
the layers are ready. It’s nobody’s fault.
When you look at code you wrote
in the past, do you always understand
what it does and do you still think it is
well written? I certainly don’t. Some-
times when I look at something I wrote
a few years ago, I have no idea what I
had in mind when I wrote it. At that
time, it probably fulfilled its purpose,but today, I would like to change the
code a little, and I have a difficult task.
When we write new code, we focus
on the problem we have to solve—we
know the context and the requirements.
We can keep all these in mind. But with
time we forget some of these things,
we don’t remember the context the
code was written in. I have heard this
saying: “If you look at your code from
six months ago and you don’t know
what could be improved, it means you
haven’t learned anything in the last six
m o n t h s .”Butterfly Effect
In chaos theory, the butterfly effect
says a slight change in the initial condi-
tions can drastically alter the result
at the end. One way to describe this
theory is with the flutter of butterfly
wings in Africa causing a whirlwind
in Australia. It sounds absurd, but you
can only laugh when you see something
like that in the code. I won’t count how
many times I changed one or two lines
in some class, seemingly unrelated
to other classes, and later something
exploded just before the deployment
or even worse—after it. Legacy systems
very often have the form of spaghetti.
You pull on one thread, and you don’t
know what it’s connected with or what’s
on the other end.
The butterfly effect occurs most often
when someone who is too autonomous
works on the code—someone who
knows best. It’s hard to convince them of
an alternative solution. Once they write
code, they won’t let anyone else touch it,
defending it like a young lioness. They
haven’t even heard about code review.
Yet, it would be enough to discuss the
code within the code review, and we
could at least avoid some mistakes.
As programmers or architects, we
decide about the architecture of our
application—similarly to traditional
architects, who design buildings like
skyscrapers. It sounds similar, but these
roles couldn’t be more different. In the
IT world, we have an incomparably
higher level of uncertainty, which is
not the case when building physical