Just as a real-life, related example (eg., not a âfeed industry vs engineeringâ debate):
I once ran a small software-based company. There was an âadd-onâ package I could buy that would add new services. I checked it out, liked it, but saw many flaws and issues with the user interface/services. I arranged to buy the source code and the right to modify it.
The code was 340,000 lines long. It took me 2 months just to read it over, make notes, and feel I understood what all the code/variable/function interactions were. Then I started modifying. I tested everything I did on my separate test system. As soon as I would post it on the active server, 2 times out of 3 something unexpected would bug out. I would stay up for hours, sometimes days, debugging the problem (which generally only happened when several dozen people were doing different things with the code, not when I and one volunteer hammered on it).
By the time it was âfixedâ, the code had just under 1.5 million lines, it had taken 6 months, many bugs, and tons of overtime on my part. I literally could have made notes myself on the things I liked about the original program and written it from scratch in half the time. Of course, at the start, spending 3 months to write some code I could buy for 800 bucks seemed silly. Oh hindsight, where are you when we need you? (This was a quite small code package btw, compared to todayâs games)
Anyways, to make a long story longer: Yes, CCP should fix bugs and âlegacyâ issues. Yes, they should update clunky old code. No, they shouldnât use âlegacy codeâ as an easy excuse. Yes, legacy code is a horror, especially after the people who wrote it have left. No, you canât tell in advance how long/hard it will be to re-code a legacy section and integrate it back with the rest of the code.
The general rule anywhere I have worked is: "Unless it is really, really broken, or you can show me in advance that it will make a profit, then donât try fixing it.