

Ask HN: Strategies for converting 1M line Enterprise system to new language. - HarrietJones

We have a million+ line system (Accounts, order, stock, etc) that's written in a programming language that's creaking a bit at the edges. I mean, it's old. Every time we consider rewriting it in a new language, the scale of the task puts us right off. As a consequence, we're still coding using a programming language from the 1980's and new features take four to five times longer than they should to develop. It's hugely frustrating.&#60;p&#62;What strategies, stories and advice do people on Hacker News have for coping with this increasingly difficult situation? How did you reboot? Anyone been through the same and come out the other side stronger?&#60;p&#62;#I've not identified the language we're using because it's a small community and I don't want to be identified.
======
itsprofitbaron
From the information you’ve provided so far, it sounds like you need to write
a _technical spec_ because, if the code is as bad as you say it is etc (it’s
hard to know without knowing what it is, although I can understand why you
don’t want to reveal it) then there probably isn’t a real spec either. This is
a worthwhile investment as you’re going to have to write a detailed and
comprehensive spec, if you are going to do a rewrite anyway but make sure you
cover every single aspect in detail relating to the current functionality
although, as you can investigate the behaviour of the system it should be
straightforward. Likewise, you can also include suggestions of what could be
improved but note them as “improvements” rather than replace it with the
current functionality so you know what’s going on.

Once you’ve wrote the spec, you’re probably going to discover the system is
more complex than your immediate impression. Again from the information you’ve
provided it appears you are more interested in doing a rewrite – “the scale of
the task puts us right off” and “It's hugely frustrating” – than anyone else
anyway (I might be wrong but that’s how it reads). As a result you may decide
to _refactor_ instead – something I’d recommend (although without having
knowledge of the codebase it’s hard to make a perfect decision here) -
although even if you decide to refactor, you still have a detailed spec to
work from going forward.

However, if after writing the spec that you feel it’s still beneficial to do a
complete rewrite then, you have a strong technical spec to work from and you
can use it to argue your case going forward. Although if you end up doing the
rewrite then you should definitely continue to support the existing code base
in production until the new code is ready, and on the first release of the
rewrite you should minimize the implementation of new features by keeping the
focus on re-implementing existing features before, eventually adding the new
features going forward.

------
dragonwriter
> Every time we consider rewriting it in a new language, the scale of the task
> puts us right off.

It should put you off. Don't do that. Rewriting -- as a single effort -- a
working, large enterprise system is pretty much guaranteed to be an expensive
failure.

Instead, as it becomes necessary to make changes to components, look for
opportunities build new components using modern technology, in a way which
lets you decommission components of the existing system in favor of interfaces
to the modern components.

 _Eventually_ , you may end up rewriting the whole thing this way, but by
rewriting in distinct bits (and focussing on the parts that would need to
change whether or not you were changing the underlying technology) you avoid
throwing out the parts that are good enough, and you keep the scope of
individual work efforts to manageable levels.

Its probably easier to get buy-off on this, since the risk involved with using
new technology for a component upgrade with limited scope and cost is a lot
smaller than the risk involved with committing to a full rewrite that ends up
an all-or-nothing proposition. And once using the new platform for a component
proves itself once, the fight to get to use it for the next bit that needs
upgrading should be even easier.

------
caw
I wasn't there for this particular product refresh, but I heard that one
product version was put on life support (critical bug fixes only, no new
development), and the company took some time to redefine the requirements, and
re-write the software. Requirements that were held in the old version weren't
needed in the new one. The new solution was less complex than the old one and
it replaced, so it wasn't a straight conversion. The product was also able to
leverage a lot of internal code libraries.

------
orangethirty
Is this a desktop based system? Intranet?

~~~
HarrietJones
Though I'd like for the new version to be Web only.

~~~
orangethirty
Start decoupling functionality into stand alone module. Have the module serve
data through a ReST API. Say you got the accounting part of the system. Take
all of their operations, and move them over to an MVC pattern that serves pure
data (no presentation). Then build the front-facing application around the
APIs. This allows you to plug in/out functionality, handle complexity, and use
of any language you may want. Problem is, if not handled correctly, you could
have a lot of cross pollination with the APIs. But since the APIs will be
stand alone services, all bad code will only rest on the front end app.

