Ask HN: Strategies for converting 1M line Enterprise system to new language.
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.<p>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?<p>#I've not identified the language we're using because it's a small community and I don't want to be identified.
4 comments
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.
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.
> 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.
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.
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.
Is this a desktop based system? Intranet?
Though I'd like for the new version to be Web only.
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.
desktop based system with some web stuff and some console mode stuff (dos)