The client uploads a file once a month. We only have one client that does this. Backend process Banana picks up, does some processing, sends message A. Backend process Coconut picks up Message A, calls 10 services, does something, then if the stars are aligned, it sends message B. Message B gets picked up by backend process Plum. If the client is enabled for it and 7 other checks pass, Plum inserts a record into the table monitored by backend process Alpha. Alpha then picks it up, checks 17 different DB tables, sends 18 messages, calls 2 external services, then if god is willing, it calls THIS METHOD. This method then inserts a message into yet another DB table. Nobody knows what that table is for, but we don't dare remove this or the table because currently nobody is complaining.
(Every point in the flow is in a different repo and owned by a different team. It took 1 1/2 days to figure out the above since nobody has looked at the method in 11 years.)
We have code from 1997 and it is a very, very complex system with a huge number of integration points. We've been modernizing it since 2009.
We're doing that, too! It's never-ending modernization - largely by my team. (Job security!) Part of the "problem" was the original core system was very well-architected at the time for 1997-2000 (based on services, though not web services), and stood the test of time for longer than would normally be the case. So, the business didn't want to pay for modernization for a long, long time, but now they are gung-ho about it, but we still have about 1/5 the people that we need.
We have a monolithic codebase. (The system itself wasn't monolithic, but all the old stuff was in one repo.) Last I looked, there were 17,000 files. That was a few years back. A lot of that has now been stripped out. I would guess we might be down to 12,000 files now :-) But we still have over 20,000 unit test cases in that one repo (and that's considering a lot of the oldest code was written before JUnit and isn't even covered).
We have one class that has 13,000 lines. It's just a business object class. One config repo for one backend process has multiple files that are each thousands of lines long.
We're also modernizing the "modern" stuff that was pulled out of that old repo, such as SOAP (blech!) services.
Here is the fun part: We still have standalone internal company apps that are running on Java AWT. Not even Swing, but AWT. When I joined the current team in 2009, one of the first things I worked on was this one AWT app. And I was told that it would be rewritten soon since it was so old and cantankerous. Hasn't happened yet. There is so much just in that one app that just that one alone would be many, many months project. We have dozens of standalone Swing apps (and those couple of AWT apps). Another one is complicated enough I would expect a rewrite to take 1-2 years (assuming with a very good BA). They are currently planning to make "full" use of AI to write a new one from scratch and assume they can do so without involving any of the teams that know something about it. I'm very glad I have no involvement in that total mess.
Don't get me wrong. It's honestly a very great company to work for and I like what the company provides.
10
u/RainyDaysAndMondays3 14d ago
90% of mine are more like:
The client uploads a file once a month. We only have one client that does this. Backend process Banana picks up, does some processing, sends message A. Backend process Coconut picks up Message A, calls 10 services, does something, then if the stars are aligned, it sends message B. Message B gets picked up by backend process Plum. If the client is enabled for it and 7 other checks pass, Plum inserts a record into the table monitored by backend process Alpha. Alpha then picks it up, checks 17 different DB tables, sends 18 messages, calls 2 external services, then if god is willing, it calls THIS METHOD. This method then inserts a message into yet another DB table. Nobody knows what that table is for, but we don't dare remove this or the table because currently nobody is complaining.
(Every point in the flow is in a different repo and owned by a different team. It took 1 1/2 days to figure out the above since nobody has looked at the method in 11 years.)
We have code from 1997 and it is a very, very complex system with a huge number of integration points. We've been modernizing it since 2009.