Hacker Bits, June 2016

When is rewrite the
answer?
Joel Spolsky made strong arguments
against rewrite and
suggests that one should never
do it. I’m not so sure about it.
Sometimes incremental improvements
and refactoring are
very difficult and the only way
to understand the code is to
rewrite it. Plus software developers
love to write code and create
new things – it’s boring to read
someone else’s code and try to
understand their code and their
‘mental abstractions’. But good
programmers are also good
maintainers.
If you want to rewrite, do it
for the right reasons and plan
properly for the following:
• The old code will still need
to be maintained, in some
cases, long after you release
the new version. Maintaining
two versions of code will
require huge efforts and you
need to ask yourself if you
have enough time and resources
to justify that based
on the size of the project.
• Think about losing other opportunities
and prioritize.
• Rewriting a big system is
riskier than smaller ones.
Ask yourself if you can
incrementally rewrite. We
switched to a new database,
became a ‘Service Oriented
Architecture’ and changed
our protocols to binary, all
at the same time. We could
have introduced each of
these changes incrementally.
• Consider the developers’
bias. When developers want
to learn a new technology or
language, they want to write
some code in it. While I’m
not against it and it’s a sign
of a good environment and
culture, you should take this
into consideration and weigh
it against risks and opportunities.
Michael Meadows made excellent
observations on when the
“BIG” rewrite becomes necessary:
Technical
• The coupling of components
is so high that changes to a
single component cannot be
isolated from other components.
A redesign of a single
component results in a
cascade of changes not only
to adjacent components, but
indirectly to all components.
• The technology stack is so
complicated that future state
design necessitates multiple
infrastructure changes.
This would be necessary in a
complete rewrite as well, but
if it’s required in an incremental
redesign, then you
lose that advantage.
• Redesigning a component
results in a complete rewrite
of that component anyway,
because the existing design
is so fubar that there’s nothing
worth saving. Again, you
lose the advantage if this is
the case.
Political
• The sponsors cannot be
made to understand that
an incremental redesign
requires a long-term commitment
to the project.
Inevitably, most organizations
lose the appetite for
the continuing budget drain
that an incremental redesign
creates. This loss of appetite
is inevitable for a rewrite as
well, but the sponsors will
be more inclined to continue,
because they don’t want
to be split between a partially
complete new system
and a partially obsolete old
system.
• The users of the system are
too attached to their “current
screens.” If this is the case,
you won’t have the license
to improve a vital part of the
system (the front-end). A
redesign lets you circumvent
this problem, since they’re
starting with something new.
They’ll still insist on getting
“the same screens,” but you
have a little more ammunition
to push back. Keep in
mind that the total cost of
redesigning incrementally
is always higher than doing
a complete rewrite, but the
impact to the organization
is usually smaller. In my
opinion, if you can justify a
rewrite, and you have superstar
developers, then do it.
Abandoning working projects
is dangerous and we wasted
an enormous amount of money
and time duplicating working
functionality we already had, rejected
new features, irritated the
customer and delayed ourselves
by years. If you are embarking
on a rewrite journey, all the
power to you, but make sure
you do it for the right reasons,
understand the risks and plan
for it. •
Reprinted with permission of the original author. First appeared at codeahoy.com.
54 hacker bits