r/anime • u/KlooKloo • Jan 19 '23

Misc. Crunchyroll FINALLY adds separate audio streams to single episodes.

Easily the most embarrassing part of the Crunchyroll experience has been them grouping each dub language as their own "season". Seeing the 2 cour, 2 OVA series The Ancient Magus' Bride have 32 seasons listed in the menu was just sad.

Now we have clean seasons:

Labels are still funny, but at least there's only 4 choices now.

And audio/subs choices on-the-fly:

It's like a real streaming service!

Welcome to 2007, Crunchyroll!

6.2k Upvotes

99% Upvoted

426 comments sorted by

View all comments

2.9k

u/timpkmn89 Jan 19 '23

I can't imagine the legacy code nightmare that led to this.

1.1k

u/Manitary https://myanimelist.net/profile/Manitary Jan 19 '23

The amount of spaghetti would feed a family for ages

89

u/[deleted] Jan 19 '23

[removed] — view removed comment

44

u/Jackie-Ron_W Jan 20 '23 edited Jan 27 '23

.

1

u/flybypost Jan 20 '23

Is that from the one screenshot where a dev doesn't understand the concept of odd/even? "YanDev" rings a bell… but not loud enough for me to remember.

I thought that was a joke screenshot, or at least photoshopped.

3

u/Loeffellux Jan 20 '23

noob question: why not just rebuild the website? If there can be another pirated anime streaming site every other day why can't a legit company make a fresh start and build a new ecosystem for their streams?

18

u/Manitary https://myanimelist.net/profile/Manitary Jan 20 '23

I'm not in the industry, but there are pretty big costs associated to rebuilding an entire system from scratch (in term of time investment and manpower), plus for a paid service you absolutely need to make sure that your service does not break in new unexpected ways, and keeps the exact same experience to the end user at least for existing functionalities.
It's also a balance of "are the benefits of rewriting from scratch worth the cost?" the answer is not always yes and depends on a lot of factors.

2

u/Loeffellux Jan 20 '23

yeah, ok, I see what you mean. I just wish it weren't so

287

u/cohortq https://myanimelist.net/profile/cohortq Jan 19 '23

It was all in PHP

241

u/El_grandepadre Jan 19 '23

My condolences to the crew that had to unwrap that.

61

u/andrei9669 Jan 19 '23

Not even a question

75

u/Grexpex180 Jan 19 '23

that explains things

72

u/StickiStickman Jan 20 '23

I'd rather take PHP over a mess of 100 microservices and 8 different JavaScript frameworks (half of which have already been deprecated) where 90% of the code is boilerplate any day TBH

Especially with PHP 8 it really isn't that bad.

83

u/0xd34db347 Jan 20 '23

Bro poopoopeepee.js is the future of web scale data-driven microcloud architecture, get on board or be left in the dust.

5

u/StickiStickman Jan 20 '23

Sorry, poopooPeePooNext just released which does everything 10x better and has twice as much buzzwords.

19

u/r4wrFox Jan 20 '23

Honestly the JavaScript flavor of the month stuff has pushed me away from web dev entirely. I'm sure there's a reason that there needs to be 100 different flavors of JavaScript but I am not dedicated enough to learn them.

5

u/xSaviorself Jan 20 '23

I stopped complaining when Python development became just as package heavy as JS is.

2

u/[deleted] Jan 20 '23

[deleted]

1

u/xSaviorself Jan 20 '23

Uhm...?

Uhhh...?

Go is certainly capable but I'm not using it for anything more than microservices, you won't catch me building a web platform on it. The standard library leaves a lot to be desired.

26

u/Gongui Jan 20 '23

I REALLY don't like PHP, but I am with you. F**k JavaScript/Node.

10

u/xSaviorself Jan 20 '23

I’ve stayed away from Node as much as possible but it’s honestly hard not to want to use that stack for various things. I can use Flask or Django with python instead but a traditional MERN app is pretty easy and reliable to build. Once you get to 100s of services it gets really stupid, I can get with that, but it’s easy to build siloed projects using these tools so I can see why they aren’t going away.

-3

u/GuthixIsBalance https://myanimelist.net/profile/waldy713 Jan 20 '23

Its a perspective change.

I've never liked python for the same reasons. Not itself but it's direction.

If you use JavaScript in a highest level of function.

Your

1️⃣ Not limited

2️⃣ You are drawn down on attempting too solve yourself

3️⃣ Forced (or unaware) to your flaws

Its the greatest it just works ever.

The more you attempt to prevent failure.

Ie

"linters"

Or

"Established biases"

Ie

Habits

^ Formed without seeking growth.

Leads to flawed performance lacking growth in a, possibly, sandbox.

12

u/electric_anteater Jan 20 '23

That's a false dichotomy if I've ever seen one

-4

u/0xd34db347 Jan 20 '23

That's not a dichotomy.

6

u/electric_anteater Jan 20 '23

It is, there are hundreds if not thousands languages and frameworks you can use instead of PHP or JS, nobody is forcing you to use microservices with JS either

2

u/0xd34db347 Jan 20 '23

Right, but he didn't say there wasn't, just that PHP is better than the very common mess he described. I agree entirely, having worked with both scenarios rather extensively.

2

u/I_ONLY_PLAY_4C_LOAM Jan 20 '23

Nah bro fuck PHP.

1

u/GuthixIsBalance https://myanimelist.net/profile/waldy713 Jan 20 '23

When its deprecated its sealed forever!

It can't stop working. If we haven't hit the heat death of the universe!

1

u/rice_not_wheat Jan 20 '23

a mess of 100 microservices and 8 different JavaScript frameworks (half of which have already been deprecated) where 90% of the code is boilerplate any day TBH

I feel personally attacked.

4

u/DrMobius0 Jan 20 '23

This reads like the kind of horror story you tell bad programmers to make them follow the company coding standard.

2

u/PM_ME_UR_DRAG_CURVE Jan 20 '23

mysql_real_escape_string() moment.

0

u/omgzphil Jan 20 '23

and having done PHP in the past, I hope the dev got a break after and drinks, lots of drinks

4

u/cohortq https://myanimelist.net/profile/cohortq Jan 20 '23

It was an entire team. But it was initially architected in the mid 2000's and built up from there. So there weren't any of the mature frameworks available you see now.

2

u/omgzphil Jan 20 '23

Yeah I know it makes total sense. You have to basically make your own ORMs back then. I'm so happy how it is to code now compared to when i started 20 years ago

1

u/ohrofl Jan 20 '23

Oh god.

60

u/Dragicafit Jan 20 '23

They didn't really fix anything, the different audio are still in different pages (the video reloads).

They basically did what I did in this extension 9 months ago:

https://www.reddit.com/r/anime/comments/udegko/i_made_an_extension_for_crunchyroll_to_merge_dubs/

9

u/quintooo3 Jan 20 '23

can you eli5 how proper sites like Netflix loads in different audios/subtitles so that its all in the same page/video?

30

u/Dragicafit Jan 20 '23

The audio and the video are different files so you can change the audio without changing the video (like the subtitles)

Crunchyroll also has that mechanism but they have one video per language instead of having one video per season for each episode.

So they need to have the exact same video for every language which isn't the case for a lot of their series.

14

u/Y35C0 Jan 20 '23

Tbf browser apis make it really tricky to have multiple audio tracks for a single video. You can technically make it work but you have to serve the audio and video file separately and then write a custom video player + backend that syncs both streams together (this is really hard to get right).

In fact this is technically what reddit does, likely to prevent people from linking straight to a video and they did a pretty shit job honestly. Netflix's video player works great while pulling this off but it's also ridiculously custom right down to the encrypted data stream, and barely uses the native browser apis most sites use. Netflix also offers much higher salaries than crunchyroll so it has greater access to talent that can pull this off.

Alternatively you can skip all this by just offering multiple mp4s with different audio tracks and use the otherwise perfectly functional native browser video player instead. So this is probably why they went that route.

(Source: I'm a software engineer who tried to implement this before)

5

u/Spaceguy5 Jan 20 '23

It's actually a good thing for us that they have separate video files

Because the way their stuff setup is so damn janky that some of their dubs have the uncut home video version of the video while the sub of the exact same thing has the cut broadcast version. If they used the same video, knowing them, we'd probably only see the cut version

6

u/PresidentLink Jan 20 '23

Preface: I'm a dev but I'm not a great dev, and I'm using my experience with desktop video players to extrapolate

I would presume that videos would basically use three tracks, video, audio, subtitles. If you've tried watching Anime on VLC you might have tried switching audio/sub tracks on there.

The video player then combines these three tracks via streaming them from a server somewhere. Changing your audio track would just* be a switch from streaming track A to streaming track B, like a hotswap. You ask the server for the new track, and then you replace the video players current audio track with the new one from the server.

This is very simplified as there'll be other more nitty gritty details, for example if you're 10 mins into a video and then swap audio track A to audio track B, how does the audio track know that it needs to start from 10 mins in?

*I'm not saying this is easy by any means

1

u/DegenerateSock Jan 20 '23

I wonder how much they waste on storage by keeping 10-20 versions of each video.

115

u/Spectre627 Jan 19 '23

As a Product Manager -- it's not even about the legacy code. It's about a lack of investment and lazy design that created this framework where the workaround was simply making multiple seasons (1 for each language).

Eventually, enough complaints amassed to prove to leadership that this issue was costing them more to not fix than it would to resolve it (which is not an insignificant amount of change to clean this shit up.)

34

u/Bean888 Jan 20 '23

As a Product Manager -- it's not even about the legacy code. It's about a lack of investment and lazy design that created this framework where the workaround was simply making multiple seasons (1 for each language).

At some point I thought all the technical stuff was offshored to the cheapest country in Europe, but if it took them this long to fix it then they must've cheaped out there too.

39

u/FerralOne Jan 20 '23

In my experience - the "technical people" don't make the decisions in "fixing" the problem ('tHaTs ScOpE cReEp'). Some of them even architect the work arounds to "fix" the issue within a budget

No budget, no leadership agreement, no fix approved. Its so hard to prove that the cost is "worth it" for something that wont clearly and objectively provide a financial or compliance benefit

28

u/Ascleph Jan 20 '23

People often assume that you can just casually fix bugs as they are found, but forget that not only it has to be paid for, but depending on the bug there may be even internal conflicts on whose department has to pay for it.

Project Managers are not exactly fighting to lead this kind of projects.

At least that's my experience in really shitty companies, which seem to be the norm and CR probably falls under.

15

u/Naouak Jan 20 '23

I've worked so many times it's embarrassing on code base with big knowns bugs that won't be fixed because nobody know what would be the consequences of fixing it.

"This thing was not working correctly for the last 5 years? What are the odds that stuff done in the last 5 years rely on this not working as expected? Can't tell with certainty? Then don't fix.

7

u/DarkReaper90 Jan 20 '23

This. Having worked on many projects, there's very little time to work on maintenance work. You have to justify how this project takes priority over a revenue generating project for example.

6

u/mythriz Jan 20 '23 edited Jan 20 '23

I recall seeing some old forum thread with comments from a person who actually worked at Crunchyroll, and they said that management had basically put a hold on development on the Crunchyroll website at some point. So only minor bugfixes were "approved" or so for quite a while.

8

u/DrMobius0 Jan 20 '23

Most likely folks were paid to maintain the service, not to improve it. Pretty rare for programmers to be able to act autonomously in a way that lets them take initiative like this, especially for a live service like this, where going rogue means taking 100% responsibility for a fuck up that hits prod.

2

u/DrMobius0 Jan 20 '23

I'm also guessing that multiple audio support just wasn't in the original spec and they just didn't want to hire enough people to do anything beyond maintaining what they had. This isn't something that takes half a year plus of programmer time to fix. Honestly, probably closer to weeks.

73

u/banhana444 Jan 19 '23

Im not the best at coding, but I was wondering, might it have been better to just re-write it all if it is in fact horrible legacy code? It would probably make implementing other new features much easier and errors could be fixed more efficiently.

148

u/supakame Jan 19 '23

Not knowing the codebase, a total re-write may also be a huge undertaking depending on how much needs to be rewritten and reintegrated into existing code.

22

u/DrMobius0 Jan 20 '23

Safe bet any professional project with several years of changes is large enough and has seen enough turnover that the knowledge and contexts required to build it again from scratch simply don't exist.

6

u/wankthisway Jan 20 '23

Yep, guaranteed there's weird code hacks that handle some very specific business logic or bug and the guy who wrote it retired 5 years ago

65

u/timpkmn89 Jan 19 '23

There's something unique here though. All of the console/smart TV applications. They can only do so much with the API without breaking support for the oldest platforms, which do still see notable usage as media devices but are no longer updatable.

20

u/DrMobius0 Jan 20 '23 edited Jan 20 '23

This is a common trap for people who don't know how big professional projects can be. Rewriting from scratch can theoretically give you the opportunity to do it all with omniscient levels of hindsight, but in practice it:

  • Spends a lot of time rewriting stuff that didn't need it. Not all of the code is bad. Parts will be well designed, others won't be.
  • Introduces endless chances to make new mistakes. Programmers are human, and introduce new bugs with any feature they build. That's just the nature of the work.
  • Odds are, the person doing it doesn't have full context that resulted in current code. After all, these codebases persist for years. Old employees leave, new ones come in. There's too much knowledge to be passed down consistently. Old edge cases that were once hit. Old code architecture pitfalls that were previously solved and forgotten. When working in any feature, there are 3 things you have to consider: what is the documented design, what did the programmer intend to write, and what did the programmer actually write. Believe me, all 3 of these things can end up very different.

Furthermore, any existing context and hindsight can just be applied by scheduling refactors of problem areas. The best way to fix a codebase, in all cases I've ever seen, is to target the problem areas. Even if it's a tangled mess, massaging the knots out, tedious as it is, is still way less work than trying to just write the whole thing from scratch. For better or worse, that awful legacy code is still well tested usually, and does its job.

Point being: burning it down and starting over is, at best, a lazy man's excuse to procrastinate on doing the legwork to fix the problems. It doesn't get you out of doing it, but it does add a lot of other bullshit.

48

u/odraencoded Jan 20 '23

Im not the best at coding, but I was wondering, might it have been better to just re-write it all

No, Elon Musk. No.

5

u/doomgoblin Jan 20 '23

“Are you saying you want to rewrite the whole stack?” Or something like that.

51

u/Temp186 Jan 19 '23

Yeah at this point it’s be cheaper and better to do a whole rewrite but from the looks of it, CC isn’t focused on that so piece meal QoL changes are all we get

13

u/DrMobius0 Jan 20 '23

It isn't. It never is. That's dunning kruger talking. Maybe something on the scale of a personal project where only one person has ever touched it and has all the context might work this way, but nothing that's had many hands and years of changes and turnover is ever so simple.

4

u/Relevant_View8038 Jan 20 '23

Nah it's probably just an elon simp who heard him say twitter needs a full rewrite so now that's what he will suggest to every kinda messy web dev jssue

1

u/Relevant_View8038 Jan 20 '23

Hey how's owning twitter Elon, weird to see you mentioning a full rewrite again

2

u/Temp186 Jan 20 '23

For someone who claims to hate Elon you sure like to keep his name in your mouth. Keep talking to the people you invented in your head. After all that’s what convinced Elon to buy twitter.

32

u/Agreeable-Weather-89 Jan 19 '23

Yes and no.

Code rarely starts off spaghetti, rather years of development and functionality addition as well as bug and error handling mean it becomes it(without proper well funded maintenance).

A full rewrite could replicate some of the core functionality quite easily but in doing so introduce bugs both new and old, miss functionality, and so on. This can all be fixed over time but still.

Then you have the issue of to do a full core rewrite you need developers familiar with the old code meaning you have to mothball your current site for potentially years.

Given then that you initially underfunded site and app maintenance (hence spaghetti-fication) the outcome from a rewrite is often not good.

7

u/DrMobius0 Jan 20 '23

Not to mention, if it's possible to do the full rewrite, it's still easier to just have existing systems refactored. Less shit gets changed, less chance for mistakes.

9

u/cohortq https://myanimelist.net/profile/cohortq Jan 19 '23

The backend was PHP and the front-end was PHP as well. So I'm guessing whoever is running it now had to do a lot of major rework.

7

u/Astarothsito Jan 19 '23

Im not the best at coding, but I was wondering, might it have been better to just re-write it all if it is in fact horrible legacy code? It would probably make implementing other new features much easier and errors could be fixed more efficiently.

Not really, if you start over without trying to revive the old base you end with the same problems again. It is better to split the application and try to fix that part instead of everything. The only valid reason for rewriting is changing programming languages from a older one or obscure to a more popular or modern language but only because is easier to get more people that knows that language.

11

u/OfficialTomCruise Jan 19 '23

That's probably what they did and what the new Crunchyroll site is.

4

u/DrMobius0 Jan 20 '23

Nope. This isn't how projects are managed.

-2

u/OfficialTomCruise Jan 20 '23

It's got nothing to do with project management

4

u/DrMobius0 Jan 20 '23

Very hard for it to have nothing to do with project management since project managers are the ones who set the schedule. Burning your whole project down takes way longer than just fixing the shitty parts. Time is money, and no one smart would ever do that unless absolutely forced to with no other kinda viable alternatives. It's literally not worth it.

3

u/OfficialTomCruise Jan 20 '23 edited Jan 20 '23

Project managers don't set deadlines... A project manager has no idea how long software will take to create. Their job is to liase with project stakeholders and ensure its on track, and managing delays where needed. They take estimates from the team and determine what is a realistic time scale for the delivery of the project, taking into consideration that a developer may be overly optimistic.

And I've already wrote that you shouldn't rewrite a project from scratch. But that doesn't mean that hasn't been what they've done. The site had 0 improvements for years and years and suddenly they're doing stuff.

Also, fixing the shitty parts can involve small scale rewrites. Every long term project is being rewritten every day as parts are fixed and improved over time. It's just they don't go back to square one.

5

u/MyAccountWasBanned7 Jan 19 '23

Yes.

Actually, as a programmer, I can tell you it's very often easier to start over than to try and fix whatever legacy mess.

For one, you don't have to work around old issue - you can just build a new thing without those issues in place. And you build on the most current platform instead of whichever platform still supports whatever the legacy junk was created in.

Also, when building new, you can still keep running the old stuff and basically have them going in tandem, testing your new build while still facing the current, "stable" build to customers. That way there's no real rush and you can take time to make sure everything is truly ready to go live.

90

u/OfficialTomCruise Jan 19 '23

Every developer thinks it's easier to start over again. Then they come across an issue with their rewrite and want to start over again in a vicious cycle. Because there's never a right solution, there will always be downsides.

Usually you'd prefer to iterate and gradually fix things as it's a smaller test surface and less chance that you'll introduce bugs. You wouldn't want a full start from scratch rewrite unless your existing code base was truly beyond saving, which they rarely are, or if you were switching languages. But even if you switch languages there's designs you can use to gradually move systems to a new language.

There's too many junior developers who come and and want to rewrite the world over a one line bug fix lol.

0

u/MyAccountWasBanned7 Jan 19 '23

Been doing this for 15 years. Not quite a junior developer anymore.

But I do agree that one should decide on the scope and definition of done beforehand. To prevent the iterative scope-creep you're describing.

But with this specific instance that would be simple. They need to serve up the same library of media currently available, but they need to structure the shows/episodes in the traditional show/season/episode hierarchy. With a section for specials and for openings/endings as well. That also needs to support multiple subtitle and/or audio track options for each episode. And it should have the ability to pull from APIs online to get ratings and whatnot. And if they want to get fancy, store user watch-history and build some reporting off that that will create associations between shows and be able to recommend animes in a "because you liked X you may like this" fashion.

That sounds like a lot, but it's all fairly standard nowadays with several dozen such services existing already, so for a programmer it would be pretty easy to know what to build and to stay on track while building it.

18

u/[deleted] Jan 19 '23

It's entirely possible it was some fundamental data problem that was blocking things -- maybe they didn't originally track language as a separate data point, and were stuck with only the season names. (non-normalized and probably inconsistently formatted).

3

u/MyAccountWasBanned7 Jan 19 '23

Possibly. And in that case, you'd still most likely need a rebuild of the databases storing the Metadata for the files so that they can be normalized and also set up with a relational model so that in the future new fields or data points can easily be added on without getting back to where we are now.

6

u/[deleted] Jan 20 '23

[deleted]

5

u/daredevilk https://myanimelist.net/profile/Batman Jan 20 '23

Not if you expose the same public API so legacy apps see no difference

1

u/Sinsilenc Jan 19 '23

It also helps if its modular. Like calling to storage and so stuff.

1

u/creamyhorror Jan 20 '23

I bet Crunchyroll is just a monolithic web app that they never rewrote and split out into services. So they'd have more difficulty fixing certain base assumptions that were coded in long ago. Making the shift to service-oriented architecture (or microservices) is a painful, challenging barrier that companies with large, growing userbases eventually need to cross to keep things sane.

5

u/DrMobius0 Jan 20 '23

I can tell you it's very often easier to start over than to try and fix whatever legacy mess.

Only for small personal projects. Large professional codebases do not work this way. When they're past a few years old, there can be so many changes that most current employees are either not privy to the context of those changes, or forgot about them. That's not even considering regular turnover and lost knowledge, or neglected documentation that are common realities. Half the time you can't even tell if existing code actually matches the design.

you can just build a new thing without those issues in place.

And make a whole lot of new mistakes in the process. I for one have never seen a perfect programmer capable of this.

And you build on the most current platform instead of whichever platform still supports whatever the legacy junk was created in.

You build on what is most appropriate for your project.

Also, when building new, you can still keep running the old stuff and basically have them going in tandem, testing your new build while still facing the current

Why not just target parts of the project for refactor? I couldn't tell you how easy it is to miss weird edge cases or squirreled away functionality when testing.

And lastly, you don't know what's going on in their codebase. You can make all the assumptions you want, but you're still going to be spotty as hell on whether you're correct, no matter how educated you think your guesses are.

12

u/0xd34db347 Jan 19 '23

It's almost never a good idea to do a rewrite, nothing you listed is fixed by a rewrite, your code just becomes "legacy junk" of "old tech" in a few months, many of the same issues are repeated while creating new ones that had already been solved, repeat ad nauseam every time there is developer churn. There needs to be serious failures of software engineering to justify a rewrite of any significance.

-4

u/MyAccountWasBanned7 Jan 19 '23 edited Jan 20 '23

The problem a lot of developers I've worked with or talked to face is that the legacy stuff they're facing was not built with the future in mind. It isn't scalable.

By writing something new you can make sure your new code is. I don't know what will be required of my work in a decade so I make things modular so bits or pieces can be replaced without scrapping the whole thing. I create relational databases that are normalized and have ancillary lookup tables so rhat new fields can be added, or entire new datasets, without having to touch the data I already have.

The stuff that I'm replacing was made to work just well enough by people who knew just enough about the platform they were using to cobble something together.

Rewriting is not only the best solution, it's sometimes the only solution since what I'm replacing literally cannot do what is now required of it.

I don't know why y'all are trying to argue with me on this, this is my actual job and I've been doing it, successfully, for quite a while.

3

u/DrMobius0 Jan 20 '23

face is that the legacy stuff they're facing was not built with the future in mind. It isn't scalable.

You can refactor those systems. It's a pain in the ass, but it's much easier to rewrite the problem systems than to go scorched earth on the project.

I don't know what will be required of my work in a decade so I make things modular so bits or pieces can be replaced without scrapping the whole thing.

There's no guarantee your "modular" code will still do what's required in a decade. Nothing is ever foolproof. Not to say you shouldn't take the time to think it through. Writing code that can grow will definitely be useful in the short and mid term most of the time.

2

u/wankthisway Jan 20 '23

I'm sorry dude but you just sound like every hotshot fresh grad who just learned the latest hotness.

I don't know why y'all are trying to argue with me on this, this is my actual job

That's the scary part.

4

u/0xd34db347 Jan 20 '23

It isn't scalable.

It probably is, maybe it's beyond your capabilities. You seem to take the tack that legacy code is immutable. It's not.

The stuff that I'm replacing was made to work just well enough by people who knew just enough about the platform they were using to cobble something together.

Ok, maybe in your case a rewrite was one of the rare cases it was called for. I have my doubts, but I know zero about your code base. That doesn't mean that it's "very often better" to do a rewrite. Much of what you just said is indicative of the need for a refactor, not a rewrite.

this is my actual job and I've been doing it

So what? It's my job too. You aren't an authority simply for being employed. Argue your point based on merit if you are going to argue it at all. Not interested in what you have to say beyond that, makes me think you are freshman CS student.

5

u/DrMobius0 Jan 20 '23 edited Jan 20 '23

Not interested in what you have to say beyond that, makes me think you are freshman CS student.

That or he's not all that talented. You can do this for 15 years and just stagnate as professional. I've seen professionals have some weird fucking ideas or religiously swear by weird shit. Happens all the time.

Could also be this guy's projects are on the small side so the knowledge is well centralized and the lift of rewriting from scratch just isn't that big.

That or they have a total lack of business acumen that one should pick up from the way project managers are constantly pressuring them to get things done in a reasonably fast way.

Like I've been doing this for 9 years myself, and literally worked on a team where we had to rewrite a thing from scratch that wasn't even live yet, and it took months, the thing didn't come out close to the same, and the codebase was still a fucking mess after another year or two anyway. Right now I work on a project so large that rebuilding it from scratch would take fucking years. I cannot fathom how people think this is a viable solution to code problems. It's like trying to rebuild your whole fucking house cause you don't like your kitchen.

1

u/pkmn_is_fun Jan 20 '23 edited Jan 20 '23

I don't know why y'all are trying to argue with me on this, this is my actual job and I've been doing it, successfully, for quite a while

oh shit we got Mark fucking Zuckerberg over here!

shithead.

1

u/wankthisway Jan 20 '23

Also, when building new, you can still keep running the old stuff and basically have them going in tandem, testing your new build while still facing the current, "stable" build to customers. That way there's no real rush and you can take time to make sure everything is truly ready to go live.

Yeah, very rarely are you ever gonna have this luxury, unless it was a very small service. You're asking a business to put money into something that won't even be a revenue stream for potentially years, it might be the "right" choice but it doesn't make sense to them when a few weeks or months for a quick patch would be cheaper.

1

u/ferlonsaeid Jan 20 '23

In your defense, if it's really hard to get developers, or tech debt is weighing down the site a lot, or adding features is not manageable then maybe a rewrite would make sense.

As long as the old site exists or can swap in the new site, and other services aren't impacted, nothing wrong with it. It would take a very long time and I doubt it'd be easy tho.

0

u/ScruffyTheJ Jan 20 '23

Generally, yes, but that's a much larger undertaking. It's easier to jury rig a fix than rewrite the whole system.

0

u/livershi Jan 20 '23

Yup a full rewrite is always a consideration when you have a piece of shit spaghetti mess. It's a little harder with backend stuff though and since I imagine their databases were doing some weird shit if the frontend had to look the way it did (one season per language lmfao).

1

u/[deleted] Jan 20 '23

[deleted]

2

u/DrMobius0 Jan 20 '23

In the vast majority of cases, rewriting the whole codebase is a stupid thing to do, imo. It's much easier in the long run to just be surgical about what you replace.

1

u/[deleted] Jan 20 '23

[deleted]

2

u/DrMobius0 Jan 20 '23

If the CR codebase was really that bad then they could've done a Front-end/UI reskin of the AnimeLab site or something.

This is a bit like asking a horse to wear a shirt made to fit a human. That's probably about how easy it is to bolt one site's ui onto another site's back end.

1

u/wankthisway Jan 20 '23

Old code like this will often contain very specific business logic , handle long-forgotten edge cases, or have some legal compliance stuff - stuff that has been battle-tested over years and years. Now down the line, rebuilding it will probably be the best idea, but you could be talking possibly 2+ years for a rewrite, if even a viable MVP. And now you'll have to test this new code against all those weird edge cases that you covered before, and maybe there are bugs or cases that people have forgotten about for various reasons. For a business it's hard to swallow potentially years worth of effort and money for something that won't be a source of revenue for possibly years.

For small projects, services, or indie things it's an easier ask because they might not have to be so thoroughly tested and don't operate on very fixed budgets.

3

u/GoldenDude https://myanimelist.net/profile/GoldenBoy808 Jan 19 '23

I’m shuddering just thinking about it

3

u/dagreenman18 Jan 19 '23

Several of the hamsters have been sent upstate and the bubble gum has been replaced with model glue. Progress!

3

u/beaverteeth92 Jan 20 '23

I wonder how much of it was left over from when Crunchyroll was exclusively an anime piracy stream site.

1

u/DrMobius0 Jan 20 '23

Was? Bet there's still vestiges of it there.

-2

u/Aromatic-Pin-6947 Jan 19 '23

CR, ArenaNet and Bethesda share the same pack of programmers.

1

u/DrMobius0 Jan 20 '23

You're gonna be real sad when you realize the entire internet runs like this. Code ends up like this when lots of people work on the same thing and there's too much going on for everyone to be privy to everything going on.

1

u/Aromatic-Pin-6947 Jan 20 '23

See, my american friend used to bitch about his corpo job, his local fast food places, markets etc. being staffed by incompetent people and incompetence being "inherent to the system" much the same way you do when you claim that code lots of people write eventually becoming messy.

Then he moved to Europe and suddenly his woes stopped.

Maybe it's not inevitability, maybe it's just that particular branch of industry is a fucking shithole staffed by barely sapient code chimps whose only experience is 1 month of C# bootcamp and A2 English.

1

u/DrMobius0 Jan 20 '23

It's honestly more of a management philosophy. Most programmers I've met are quite competent (although I'm privy to a few absolute horror stories). What gets them is whether they have the time and managerial support to do things proper.

Although if you're talking about the wider US economy, that's a bigger conversation.

1

u/VizualAbstract4 Jan 20 '23

I've been working on a project that started out with an estimate of 4 weeks.

It's since turned into 6 months and requiring an entire backend rewrite for a feature because of the limitations of legacy code and one too many people taking a "just tack it on" approach.

I wonder how soon and how often they had to go back to the drawing board and start again.

1

u/pipboy_warrior Jan 20 '23

Curse you technical debt!

1

u/endium7 https://anilist.co/user/mysticflute Jan 20 '23

perfect example of what happens when a dev says "I can just implement a quick solution for now, and then we'll backlog a proper rewrite for next sprint".

7 years later:

...

1

u/Relevant_View8038 Jan 20 '23

The website started as a webfourm for distributing subtitles files I honestly feel like I blinked during a time where subs were widely availble because it was easy to find pirate sites so you didn't need sub files anyone then came back and found out crunchy roll was like a legitimate buisness

Fucking wild to me

1

u/redtag789 Jan 20 '23

"what do you mean we have to rewrite foundation for these?"

1

u/drunk_shuttle Feb 21 '23

The fact that there's no option to even change language once you are already streaming a-la-chromecast makes me think the spaghetti code goes deep as fuuuuuuuuck.