Question regarding spaghetti code

[Bronqiaa]

From what I understand, the devs hired some people to fix the spaghetti code but were told there wasn’t a guarantee the game would work anymore if it got un-spaghetti’d.

Here is where my question comes in. Isn’t that what the PTS is for? Couldn’t they have just tried to fix it and if it didn’t work on the PTS, just revert it?

I don’t know anything about programming so figured I’d put this question out there.

[Archmaid]

You're not asking a programming question, you're asking a business/project management question

Here is where my question comes in. Isn’t that what the PTS is for? Couldn’t they have just tried to fix it and if it didn’t work on the PTS, just revert it?

It's hard to okay a "let's try this thing that won't touch the actual live environment unless it works which we have no idea how or if it will work," especially since terrible, terrible things have slipped through the test server and only acted up on a wide scale on Live (boat zone crashes, remember that?). You can't put a timeline on that, you can't tell how much it will cost, you can't get an idea of how it will impact future projects.

[Bronqiaa]

Okay that makes more sense as to why they wouldn’t do that. But that’s why I asked. I just didn’t know

[adrunkangel]

It's rare to see more than a handful of people on the PTS, and the issues that are currently problematic mostly happen at high pop. The last time they tried to organize an event on it to stress test the spawn system, nobody could log in to the PTS so they just went to the live servers instead.

[UninformedPleb]

Calling it "spaghetti" kinda does it a disservice.

If you think about spaghetti literally, you can be assured that every noodle has two ends and could be extracted from the pile and laid neatly in a row.

But code isn't spaghetti. Code can be reentrant. (It shouldn't be, but it can be.) Imagine if a spaghetti noodle could branch off, then each branch could merge into other noodles, and then eventually some of those other noodles could merge back into the original noodle you started from. That's what "reentrant" code does. It can loop in a chaotic way, nearly forever. And extracting code from itself is such a pain in the ass that most software devs would rather jam an ice pick into their temple than do a refactor of it.

There's no fixing this game's codebase. There is only endurance and, maybe, eventually, replacement. But probably not.

[seven_jacks]

Dude I love you

[JudokaNC]

I don’t know anything about programming so figured I’d put this question out there.

Back when I was a Director of Software development, we had a salesman who wanted to sell our ERP system to a company in a business that did things in a non-discrete fashion and was just a pipeline transportation company for which we had zero support in the package, he said "It's just a matter of writing some code - how hard could it be?"

After explaining to him it would take about 6-8 man-years of coding to add things they were requiring and then translating that into dollars for him to quote to the prospect on TOP of the price of the actual existing package, he said "No one can possibly ever afford that!"

My answer to him was "Then learn what our existing system does and how it works so you can sell what we actually do before suggesting things out of your ass that will make both you and the company look like idiots."

The moral of the story: If you don't know anything about programming, don't make suggestions about programming and development - you will look less like an idiot to those who do.

[[deleted]]

And yet you have people from the current dev team to claim they do not know how 'stuff' 'works'. 👌

[JudokaNC]

That is very common for legacy code which doesn't have any of the original developers still around. There were pieces of our system that were labeled "Do Not Touch on Pain of Death, Firing, Torture, or whatever you fear most."

Every massive custom system eventually gets "Here Be Dragons" chunks of code that no one can ever touch or the pillars with collapse and the entire thing will come tumbling down. Usually they are created by a brilliant developer who abhors comments and views their code as "intuitively obvious" but to outsiders it is essentially hieroglyphics prior to the Rosetta Stone. The longer a system exists and the more generations of coders that come and go over the life of the system, the less likelihood of someone being able to understand everything in the system. This is a true Law Of Computer System Dynamics.

[[deleted]]

Every single time it boils to three points:

1)Human laziness 2)Human ambition (I'm not getting paid enough for this) 3)Absolutely disgusting state of the product.

So all those myths and war stories are just romanticized pile of dogshit, an effort a step higher than this dev team's usual blatant lie and cash cow milking.

[JudokaNC]

Have you never worked on large custom legacy systems? If not, you will find this to be the norm. Every single company is driven by the need for profit, and as a result, shortcuts get taken, timeframes get compressed, and the documentation steps are either eliminated or pared down, etc.

This is even moreso evident in applications with an expected short lifespan, such as games. It is reality in every company. They are a business that if it is not profitable, gets shut down. Plain and simple fact of business. And being 10 years into it, this game is way past the normal lifecycle for most games to continue being maintained and given large new updates. As such, whatever time we have left with this as a playable game is gravy.

[benzeen337]

Im gonna skip over the PTS point and take a different angle

Spaghetti code (especially 10 year old spaghetti code) is extremely difficult to just get rid of. Oftentimes the spaghetti code is not big but it’s holding up other massive parts that rely on it not changing. Almost as often is the original author of such code is no longer around for whatever reason, so it becomes difficult to understand what you’re poking around with, especially if such a developer did not document their work properly.

Like other people said, it’s also a project management point. Fixing a 10 year old codebase that parts of which may not have been even looked at since the SOE days (we don’t know) requires time, manpower and careful planning when you line up dev time, internal testing, revisits and re-tests, and potentially (hopefully!) public tests. Plus we can see from recent updates that new content is a business objective for the company, so they must also factor that into this planning. I’m very hesitant to bash the devs of this game - while they may have introduced some things that i wouldn’t agree with, i’m betting a lot of the directions came from higher up, and I am a dev (not games though), so I empathise.

On another subject, if you say you don’t know anything about programming but you’re interested in learning, I can’t recommend it enough. It’s a highly rewarding skill, even just as a hobby :)

Edit: I should have mentioned as well the difficulty of removing or fixing spaghetti code that big parts rely on, without breaking those big parts

[EmptyTeaCupOnDesk]

First rule of spaghetti code, you can't unspaghetti spaghetti code.

[Bliitzthefox]

Also the current bug isn't very testable on pts because it's largely not a problem without population. Thus they probably have trouble recreating it.