I'm working on a side project at the moment, just a clean-up for an old customer who was acquired and needs to be migrated off our old systems and onto their parent company's systems. To do that, we need to make a single, simple calculation. About half of the time so far in the project has been taken up by trying to extract the core of this calculation from the legacy system in which it was written. By comparison, the same basic function for the "new" parts of the system was a few lines of code, since the new system is anal about storing every little bit of metadata about the things it does.
You often run into these situations in working with really large, really legacy codebases. The code has acreted rules and requirements over the years, none of them really spelled out. Some relatively simple operation is now pretty much inextricably linked into the overall functioning of the system. Poor compartmentalization of the legacy code means that side-effects happen all over the database and the code-base.
They are a PITA, you often wind up trying to whittle down the old system's code so that you can run some subset of the system as a separate process and munge the data, but you're always thinking "maybe I could just implement it in a few lines of code" in the back of your mind. You're pretty sure that if there was a proper spec you could... but there isn't... and it took years to acrete all the rules and exceptions in there... better to just hold your nose and try to make the best of it.
Pingbacks are closed.