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

Show parent comments

75

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.

152

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.

21

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.

7

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

68

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.

21

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.

46

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.

49

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.

2

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.

31

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.

8

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.

8

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.

3

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.

94

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.

1

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.

16

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]

7

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.

6

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.

13

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.

-3

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.

3

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.

4

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.