FastPass+ Most Certainly Not Coming Back As It Was

[G00fyDad]

I'm watching this thread since I really want to know about this info. As soon as someone with an inside track learns what is happening with FP(+) please let us know. I am in the early planning stages and I want to know what to expect.

 

[YorkshireT]

Where did you see that reported?

It wasn’t a bus driver. I’ve seen two different people say on two different Facebook groups that this past week they were ask to go in the FP lane and do a test scan.
No idea if true but it seems a strange thing for people to lie about- and one I saw today was just replying on a thread about park capacity increasing.

 

[flutas]

Those are great points (regarding copying software). But its my understanding (and please, someone correct me if I'm wrong) but it was more than just FP software that was modified to become the current park reservation system.....but hardware components such as servers, databases, etc. Still, it might not be as easy as buying a few more server blades, going to a server backup dated early march of 2020, unspooling the backup onto the new servers and pushing the old FP+ system live.

There's probably alot going on in the background of MDE that had to make way for the FP+ conversion park reservation system - so you now have to make sure a new fastpass system doesn't compete with it.

And again....this is all assuming they just want to relaunch the old FP+ program....and based on what we're all seeing, they might not be doing that.

ParkPass didn't "cannibalize" FastPass. Unless you consider it in the same vein that "Restaurant reservations cannibalized FastPasses and they cannibalized Hotel Bookings."

ParkPasses are a subset of FastPasses, just like how their systems already had subsets of FastPasses for different tiers (at WDW) and Shows vs Rides (at DLR).

 

[Disney Glimpses]

Can someone explain how they tore apart the FP+ system to get the park pass system working? This doesn’t match my understanding of how modern software engineering works, but I may be missing something.

Late reply but a Park Pass reservation is really just a FP+ (when you make a reservation, it hits the FP+ API). It's why originally it had the park hours as "return times" which was subsequently replaced with "open to close" and then nothing at all.

Long story short is, they made the FP+ system work for Park Pass and over the last year or so, made several modifications to it. In essence, they can easily bring back the old FP+ system tomorrow, but it would require reverting to the revision of the codebase prior to shutdown since apparently the changes to the codebase were destructive to the previous functionality (why? who knows). And reverting it would mean abandonment of the Park Pass system.

Alternatively, they could potentially bring back that old code in a new separate API and leave the Park Pass system as it is.

I am 99.9999% certain their original intent was to revert the codebase when "normal" returned. But then they came to like the Park Pass system and now are in a conundrum.

 

[MrHorse]

Not trying to "start anything" here, I am just genuinely curious, as someone with no technical / software expertise. I've seen people mention that it has been "cannibalized" and people say that you can't cannibalize software, once the code is written it's written.

As a layperson my assumption is that you would just copy and paste the same code in as many places as you need it, ha ha. Could you explain what is meant by "cannibalization"? For example, is it that you can't run competing code on the same set of hardware, like the FP readers or the app, because it will cause all kinds of glitches? Or do they only have the bandwidth to run one program or the other?

I live in the world of big software integrations.

The word 'cannibalized' is used frequently and loosely. It's hard to put a tighter definition on it than "the plan changed". i.e., We started plan X, then plan Y came along and took over.

You can't just copy code around, but the reason is more about project management, resources, data, and integrations than any kind of actual technical limitation. By and large, hardware doesn't matter. It can either do multiple things at once or you can just get more of it. (Current shortages aside.) Also, it may aid the understanding to realize that this kind of software is just MUCH, MUCH, MUCH bigger and more complex than you might expect. Thousands and thousands of files. Millions of lines of code. Written by thousands of people, most of whom have nothing to do with your organization or project. (Ironically, this is because some code can be copied around very easily.) It takes a lot of expensive expertise to control something like this.

The problem is that the people who were going to maintain one system are now maintaining another system or just another version of this system. Along those lines, code starts to 'rot' as soon as you take it offline. Normally, you keep all your systems in sync. When you make a change in one place, you update the connecting stuff so that it keeps playing nicely together. For a simple example:

• You have a reservation system that needs a 'Name', 'Arrival Date', and 'Departure Date' to make a reservation. All the systems that deal with reservations are built to provide this.
• You improve the reservation system so that it tracks the type of room you want. Now all the systems that make reservations need to provide a 'Room Preference' option too.
• If you turn on code that was taken offline before that change, it won't know to provide 'Room Preference' and it won't be able to make reservations.

That's a simple example. In practice, the changes are countless, esoteric, and documentation is often poor if it exists at all.

It's nearly unheard of to devote resources to testing and maintaining offline code. Even if you HAVE devoted resources, the odds of the work being done right are minuscule. The reality is gonna be somewhere between the work getting done poorly and it getting completely handwaved and only happening on paper. It's just really, really, hard to motivate people to put effort into something they know won't be used. Doubly so, when they know that nobody is going to verify the work. Triply so when they realize that if the company ever DOES decide to use the code, there'll be a shiny, new, budget to get it back online anyway.

On top of all that, folks just aren't going to be familiar with stuff that isn't being used. It's like reassembling something you took apart a year ago.

When you pile all that together with a handful of other considerations I didn't get into... the fact becomes that recreating a system from scratch is almost always easier than bringing an old one back online.

 

[PirateFrank]

ParkPass didn't "cannibalize" FastPass. Unless you consider it in the same vein that "Restaurant reservations cannibalized FastPasses and they cannibalized Hotel Bookings."

ParkPasses are a subset of FastPasses, just like how their systems already had subsets of FastPasses for different tiers (at WDW) and Shows vs Rides (at DLR).

thanks for the clarification!

 

[Disney Glimpses]

It's quite clear that they thought COVID-19 would be a flip a switch on and off type situation and could simply revert to normal operations after COVID-19 ended.

They didn't imagine themselves in this hybrid scenario of "normal" but also not normal, and that's why we are where we are with FP+.

 

[Ripken10]

I live in the world of big software integrations.

The word 'cannibalized' is used frequently and loosely. It's hard to put a tighter definition on it than "the plan changed". i.e., We started plan X, then plan Y came along and took over.

You can't just copy code around, but the reason is more about project management, resources, data, and integrations than any kind of actual technical limitation. By and large, hardware doesn't matter. It can either do multiple things at once or you can just get more of it. (Current shortages aside.) Also, it may aid the understanding to realize that this kind of software is just MUCH, MUCH, MUCH bigger and more complex than you might expect. Thousands and thousands of files. Millions of lines of code. Written by thousands of people, most of whom have nothing to do with your organization or project. (Ironically, this is because some code can be copied around very easily.) It takes a lot of expensive expertise to control something like this.

The problem is that the people who were going to maintain one system are now maintaining another system or just another version of this system. Along those lines, code starts to 'rot' as soon as you take it offline. Normally, you keep all your systems in sync. When you make a change in one place, you update the connecting stuff so that it keeps playing nicely together. For a simple example:

• You have a reservation system that needs a 'Name', 'Arrival Date', and 'Departure Date' to make a reservation. All the systems that deal with reservations are built to provide this.
• You improve the reservation system so that it tracks the type of room you want. Now all the systems that make reservations need to provide a 'Room Preference' option too.
• If you turn on code that was taken offline before that change, it won't know to provide 'Room Preference' and it won't be able to make reservations.

That's a simple example. In practice, the changes are countless, esoteric, and documentation is often poor if it exists at all.

It's nearly unheard of to devote resources to testing and maintaining offline code. Even if you HAVE devoted resources, the odds of the work being done right are minuscule. The reality is gonna be somewhere between the work getting done poorly and it getting completely handwaved and only happening on paper. It's just really, really, hard to motivate people to put effort into something they know won't be used. Doubly so, when they know that nobody is going to verify the work. Triply so when they realize that if the company ever DOES decide to use the code, there'll be a shiny, new, budget to get it back online anyway.

On top of all that, folks just aren't going to be familiar with stuff that isn't being used. It's like reassembling something you took apart a year ago.

When you pile all that together with a handful of other considerations I didn't get into... the fact becomes that recreating a system from scratch is almost always easier than bringing an old one back online.

I work for one of the biggest employers in the country. We have systems offline that we bring back all the time. It is much easier to take an existing system and change it to fit new needs then create a system from scratch. Rarely do we create any system from scratch. I haven't created a system from scratch in 10 years. Yes, there is things you have to update, but it is far easier then creating a complex system from scratch.

This happens in the real world constantly, and in our company, almost exclusively. You always start with something rather than nothing. No reason to recreate the wheel. Besides, with the way coding has evolved, they should have many functions that work globally that can be intergrated into "new" applications. Don't need to re-write code, or even copy and paste, you just call it into the new application to perform the task it is performing for another application.

 

[MrHorse]

I work for one of the biggest employers in the country. We have systems offline that we bring back all the time. It is much easier to take an existing system and change it to fit new needs then create a system from scratch. Rarely do we create any system from scratch. I haven't created a system from scratch in 10 years. Yes, there is things you have to update, but it is far easier then creating a complex system from scratch.

This happens in the real world constantly, and in our company, almost exclusively. You always start with something rather than nothing. No reason to recreate the wheel. Besides, with the way coding has evolved, they should have many functions that work globally that can be intergrated into "new" applications. Don't need to re-write code, or even copy and paste, you just call it into the new application to perform the task it is performing for another application.

Unless you're talking about stuff on a different scale, some specialty use case, or we've got some kinda miscommunication, that sounds... odd.

It's just so rare to even turn these kinds of systems off in the first place unless you're replacing them with something better.

The vast, vast majority of companies simply aren't turning mission-critical stuff like their storefront, inventory, financials, etc, off and on all the time and bouncing between different systems/versions.

I'd feel pretty comfortable betting Disney has never reverted to a retired reservation system once in their entire history.

 

[Parker in NYC]

I work for one of the biggest employers in the country. We have systems offline that we bring back all the time. It is much easier to take an existing system and change it to fit new needs then create a system from scratch. Rarely do we create any system from scratch. I haven't created a system from scratch in 10 years. Yes, there is things you have to update, but it is far easier then creating a complex system from scratch.

This happens in the real world constantly, and in our company, almost exclusively. You always start with something rather than nothing. No reason to recreate the wheel. Besides, with the way coding has evolved, they should have many functions that work globally that can be intergrated into "new" applications. Don't need to re-write code, or even copy and paste, you just call it into the new application to perform the task it is performing for another application.

But your company isn't Disney. Whoops!

 

[Ripken10]

Unless you're talking about stuff on a different scale, some specialty use case, or we've got some kinda miscommunication, that sounds... odd.

It's just so rare to even turn these kinds of systems off in the first place unless you're replacing them with something better.

The vast, vast majority of companies simply aren't turning mission-critical stuff like their storefront, inventory, financials, etc, off and on all the time and bouncing between different systems/versions.

I'd feel pretty comfortable betting Disney has never reverted to a retired reservation system once in their entire history.

The system is not “retired” it was turned off. We do this with our systems, it is not as hard as you are making it out to be. We can disagree, but as I said we do it in our business. I could ask someone that develops things for Disney, but it just doesn’t interest me that much when I know the answer they will give. Maybe I will next time we chat

 

[Disney Glimpses]

The system is not “retired” it was turned off. We do this with our systems, it is not as hard as you are making it out to be. We can disagree, but as I said we do it in our business. I could ask someone that develops things for Disney, but it just doesn’t interest me that much when I know the answer they will give. Maybe I will next time we chat

Not really, true. It was heavily modified to accommodate the Park Pass system (which is in the system, a FastPass+ reservation). It cannot simply be turned back on.

 

[MisterPenguin]

Not really, true. It was heavily modified to accommodate the Park Pass system (which is in the system, a FastPass+ reservation). It cannot simply be turned back on.

So... you're saying there's going to be a FP+ line to get into the parks?

 

[Joel]

So... you're saying there's going to be a FP+ line to get into the parks?

You're only going to be able to ride FoP before 2 if you have a FP, and after that only if you tapped into 7DMT earlier.

 

[DisneyHead123]

Thanks those who tried explaining the mysteries of FP software in response to my question... not sure what to think, this is totally not my field, but interesting to hear different perspectives.

 

[Disney Glimpses]

Thanks those who tried explaining the mysteries of FP software in response to my question... not sure what to think, this is totally not my field, but interesting to hear different perspectives.

The truth is when they did this, they figured "hey, we'll use the FP+ system to make Park Pass and then when this debacle ends in a couple of months, we'll revert the code back to the old way."

Clearly, things are not that simple in reality.

 

[MJM]

Or simple or not isn’t the issue. There’s not been a need for it be reimplemented yet. But as capacity increases so will that need

 

[HairyChest]

On the latest Disney Dish podcast, @lentesta said fastpass + is coming back as a paid option. As a dvc owner, I really hope it’s included with my resort reservations(as well as for on property guests) just like universal has express pass included with their deluxe resort guests.

 

[TrojanUSC]

On the latest Disney Dish podcast, @lentesta said fastpass + is coming back as a paid option. As a dvc owner, I really hope it’s included with my resort reservations(as well as for on property guests) just like universal has express pass included with their deluxe resort guests.

Some form of FP is coming back as a paid option, it will likely not be FP+. It also likely will not be like Universal. They are well aware they can upcharge deluxe hotel guests for line skipping and make bank.

 

[UNCgolf]

Some form of FP is coming back as a paid option, it will likely not be FP+. It also likely will not be like Universal. They are well aware they can uncharge deluxe hotel guests for line skipping and make bank.

I wish they were going to uncharge deluxe guests for line skipping!