MyMagic+ MagicBands to begin testing in parks soon

[xdan0920]

Question: What's wrong with Everest? (If you say the Yeti you're going to surprise me, seriously.)

Why would that surprise you?

For the record, the Yeti is one of many broken or turned off show scenes on Everest.

 

[YankeeMouse]

It's probably here somewhere or somewhere on Disney, but for my sanity, here goes with my question: Do you need to have a resort reservation in order to reserve the fastpass, like you need a reservation for ADR's to get into a certain time window? We are non-Florida passholders who make frequent short trips and sometimes our reservation is made only a couple of weeks before arrival. I've gotten used to being shut out of dining but does this have a similar impact on Fastpass+ reservations?

 

[RandomPrincess]

It's probably here somewhere or somewhere on Disney, but for my sanity, here goes with my question: Do you need to have a resort reservation in order to reserve the fastpass, like you need a reservation for ADR's to get into a certain time window? We are non-Florida passholders who make frequent short trips and sometimes our reservation is made only a couple of weeks before arrival. I've gotten used to being shut out of dining but does this have a similar impact on Fastpass+ reservations?

According to the info Disney has put out you will need park tickets only to book FP+

 

[wdwmagic]

Question: What's wrong with Everest? (If you say the Yeti you're going to surprise me, seriously.)

Everest has lost nearly all of its show scene effects.

Yeti out of action.
Mountain top mist out of action.
Upper cave mist out of action.
Summit bird out of action.
Load area steam nearly always out of action.
Waterfalls intermittent.
Landscaping removed and not properly replaced.
Load area track lighting left on.

 

[Lil Fort]

People couldn't see their reservations online but they were still there. So while it was annoying no one lost anything for good.

True, nothing was 'lost'. That's why I used the words 'couldn't find'. It sure caused a lot of people some major anxiety though, which in turn caused trust issues. There were also a lot of folks who made new ADRs because they thought the old ones were lost. Those duplicates most likely kept other people from booking ADRs during some of the busier time slots, at least until the data was cleaned up by Disney. As a developer I can't fathom how a bug of that magnitude could make it through quality assurance. Something of that magnitude even making it into a beta release is a huge failure when it comes to software development. I would have loved to have been a fly on the wall at the lessons learned meeting after that release.

 

[flynnibus]

As a developer I can't fathom how a bug of that magnitude could make it through quality assurance. Something of that magnitude even making it into a beta release is a huge failure when it comes to software development. I would have loved to have been a fly on the wall at the lessons learned meeting after that release.

Was probably a 'sins of our fathers..' problem. Problems with poor data or inconsistent sources leading to the new system... designed to spec.. not through evolution... to reject the shoddy data.

 

[Lil Fort]

Was probably a 'sins of our fathers..' problem. Problems with poor data or inconsistent sources leading to the new system... designed to spec.. not through evolution... to reject the a shoddy data.

Where I work that wouldn't be acceptable. I doubt that it would be most other places either. You just can't do a large data migration without making sure that all of your data will migrate. Not unless you want a lot of unhappy customers, anyhow... If you have bad data you find it and fix it prior to the migration or you code around the issues so that everything comes across. This wasn't just a few records either. It was a widespread problem.

 

[Buried20KLeague]

Nah.. I just don't see value in jumping off the cliff before there is concrete reason to do so. I'm not losing anything from Disney right now.. no need to slit my wrists or preach the end of the world. If it comes.. I'll be right there criticizing their stupidity. But for now.. what's the rush?

Let me first say that of all the people that are on the other side of the fence on this topic from "us", I respect your opinion because you at least back your feelings with rationale. It's rationale that we disagree on, but rationale none the less. So many others that think MM+ is the cat's meow would get a pile of crap with Mickey ears stuck in it and tell us about how lucky we are that Disney offered it.

That being said... I really and truly don't understand your post above. There are a number of negatives to MM+ and FP+ that are virtual certainties, and and even longer list of probable negatives that we can arrive at with just the smallest amount of observation and a simple bit of math. You're clearly intelligent... I just don't see how you don't see what is so obvious to all of "us".

I believe you've even commented directly about @ParentsOf4 's basically being fear mongering, and I am completely clueless as to how or why. His posts have virtually drawn us a picture of how this thing is going to work, with nearly every extrapolation backed by numbers. The posts are informed, objective, and well thought out. Yet you seem to dismiss them by saying "well, we don't know for sure". But we all know where this is headed.

If I'm standing on train tracks and a train is clearly coming, I'm not going to stand there and wonder if it's going to stop before it gets to me.

 

[flynnibus]

Where I work that wouldn't be acceptable. I doubt that it would be most other places either. You just can't do a large data migration without making sure that all of your data will migrate. Not unless you want a lot of unhappy customers, anyhow... If you have bad data you find it and fix it prior to the migration or you code around the issues so that everything comes across. This wasn't just a few records either. It was a widespread problem.

I agree it was a poor migration (lack of sanity checking with real world data) - my point being that it's possible to QA something to death.. but if you aren't testing the right thing... Always a high risk when you replace a legacy system that has probably been band aided for many years... documentation could be weak or non-existant.. experience is no longer with the group.. etc. You have to be aware of the data variations to know to test them. Or do a full dry run with validation on everything..

 

[flynnibus]

Let me first say that of all the people that are on the other side of the fence on this topic from "us", I respect your opinion because you at least back your feelings with rationale. It's rationale that we disagree on, but rationale none the less. So many others that think MM+ is the cat's meow would get a pile of crap with Mickey ears stuck in it and tell us about how lucky we are that Disney offered it.

That being said... I really and truly don't understand your post above. There are a number of negatives to MM+ and FP+ that are virtual certainties, and and even longer list of probable negatives that we can arrive at with just the smallest amount of observation and a simple bit of math. You're clearly intelligent... I just don't see how you don't see what is so obvious to all of "us".

The issue is most of the 'certainties' you reference are just opinion that people really feel strongly about - not that they are any more likely to happen.

I believe you've even commented directly about @ParentsOf4 's basically being fear mongering, and I am completely clueless as to how or why. His posts have virtually drawn us a picture of how this thing is going to work, with nearly every extrapolation backed by numbers

There is the problem - you are taking his speculation as fact instead of just treating them as his guess on how it will be. That's the problem in these threads... if people just say it enough everyone believes that's the way it will be. Reality is he doesn't know anything more than you or I.. he's just speculating and extrapolating based on the limited information available. It's simply his belief supplemented with some educated guestimates. You may find it a convincing argument - but its still just guesses... and for the most part he has framed them as such... but that doesn't mean the reader will take them as such.

The posts are informed, objective, and well thought out. Yet you seem to dismiss them by saying "well, we don't know for sure". But we all know where this is headed.

I value accuracy over 'being first'. Bad information can hurt far worse than delayed information.

If I'm standing on train tracks and a train is clearly coming, I'm not going to stand there and wonder if it's going to stop before it gets to me.

An analogy that infers you have some risk involved if you don't jump soon enough. What are you risking if you don't guess Disney's full plans before they roll them out here? What did you 'save' by jumping before the real details are available?

 

[Lil Fort]

I agree it was a poor migration (lack of sanity checking with real world data) - my point being that it's possible to QA something to death.. but if you aren't testing the right thing... Always a high risk when you replace a legacy system that has probably beenband aided for many years... documentation could be weak or non-existant.. experience is no longer with the group.. etc. You have to be aware of the data variations to know to test them. Or do a full dry run with validation on everything..

You should stick to hardware Flynn, because you are way off base here. I'm starting to think that you just argue for the sake of arguing. Any development team that is charged with the task of data migration of ADRs darn well better either know or be willing to learn everything they need to know about the system they are migrating. The old system was their IP. It isn't like they didn't have the code to look at and if there is a developer who can't figure out what a program is doing by stepping through the code, then I wouldn't want them on my team. And we aren't talking legacy data here. These were active ADRs. That means they would be less than 180 days old. That should have been the focus of testing. This was a major snafu no matter which way you slice it.

 

[flynnibus]

You should stick to hardware Flynn, because you are way off base here. I'm starting to think that you just argue for the sake of arguing. Any development team that is charged with the task of data migration of ADRs darn well better either know or be willing to learn everything they need to know about the system they are migrating. The old system was their IP. It isn't like they didn't have the code to look at and if there is a developer who can't figure out what a program is doing by stepping through the code, then I wouldn't want them on my team. And we aren't talking legacy data here. These were active ADRs. That means they would be less than 180 days old. That should have been the focus of testing. This was a major snafu no matter which way you slice it.

I guess you've never worked with contractors or offshore developers? They build to spec. They don't think through 'what else be out there...' or 'what do we not know...' - they require a spec and build to it. Which results in the risk of 'Junk in.. Junk Out'. If the people writing the spec don't take in all possible scenarios.. you get nice tight code that breaks when the variations pop-up. The code monkey says 'It does what its supposed to do...' and they lack the application awareness to question the spec's completeness vs the actual business. I could add lots of stereotypes on the type of developers that act this way too.. but I'll skip that.

You also assume there is one type of data.. all conforming to the same rules. There can be multiple front-ends, all with their own types of validation storing to a system that could have been weak in data structures and enforcement. Result.. you get non-homogenuous data.. even tho externally it all looks the same because the front-ends have each over their lifetimes coded around the 'sins of our fathers..'. Take that scenario, a spec writer who only checks part of the solution.. and you can very well end up in a trap like this.

Nearly every ADR change in the last decade have been extremely tumultuous. That lends you to believe the data and tools are not as strictly defined as they should be and there is probably a lot of slop in the system.

The age of the reservations has little to do with the age of the systems used to create/modify/save them. They could be all be working out of a data store with horrible structure and each front-end with their own bandaids and traits committing records to that data store.

That's the reality of sloppy implementations that people are often thrown into. You avoid it by 'trust no one' and actually validating with real world data. But like we saw with the DL Monorail.. when dealing with legacy stuff people sometimes are just too trusting of the materials given to them and they build a perfect product that still fails.. perfectly

 

[John]

I guess you've never worked with contractors or offshore developers? They build to spec. They don't think through 'what else be out there...' or 'what do we not know...' - they require a spec and build to it. Which results in the risk of 'Junk in.. Junk Out'. If the people writing the spec don't take in all possible scenarios.. you get nice tight code that breaks when the variations pop-up. The code monkey says 'It does what its supposed to do...' and they lack the application awareness to question the spec's completeness vs the actual business. I could add lots of stereotypes on the type of developers that act this way too.. but I'll skip that.

You also assume there is one type of data.. all conforming to the same rules. There can be multiple front-ends, all with their own types of validation storing to a system that could have been weak in data structures and enforcement. Result.. you get non-homogenuous data.. even tho externally it all looks the same because the front-ends have each over their lifetimes coded around the 'sins of our fathers..'. Take that scenario, a spec writer who only checks part of the solution.. and you can very well end up in a trap like this.

Nearly every ADR change in the last decade have been extremely tumultuous. That lends you to believe the data and tools are not as strictly defined as they should be and there is probably a lot of slop in the system.

The age of the reservations has little to do with the age of the systems used to create/modify/save them. They could be all be working out of a data store with horrible structure and each front-end with their own bandaids and traits committing records to that data store.

That's the reality of sloppy implementations that people are often thrown into. You avoid it by 'trust no one' and actually validating with real world data. But like we saw with the DL Monorail.. when dealing with legacy stuff people sometimes are just too trusting of the materials given to them and they build a perfect product that still fails.. perfectly

Yea....what he said......as if I knew.

 

[Lil Fort]

I guess you've never worked with contractors or offshore developers? They build to spec. They don't think through 'what else be out there...' or 'what do we not know...' - they require a spec and build to it. Which results in the risk of 'Junk in.. Junk Out'. If the people writing the spec don't take in all possible scenarios.. you get nice tight code that breaks when the variations pop-up. The code monkey says 'It does what its supposed to do...' and they lack the application awareness to question the spec's completeness vs the actual business. I could add lots of stereotypes on the type of developers that act this way too.. but I'll skip that.

You also assume there is one type of data.. all conforming to the same rules. There can be multiple front-ends, all with their own types of validation storing to a system that could have been weak in data structures and enforcement. Result.. you get non-homogenuous data.. even tho externally it all looks the same because the front-ends have each over their lifetimes coded around the 'sins of our fathers..'. Take that scenario, a spec writer who only checks part of the solution.. and you can very well end up in a trap like this.

Nearly every ADR change in the last decade have been extremely tumultuous. That lends you to believe the data and tools are not as strictly defined as they should be and there is probably a lot of slop in the system.

The age of the reservations has little to do with the age of the systems used to create/modify/save them. They could be all be working out of a data store with horrible structure and each front-end with their own bandaids and traits committing records to that data store.

That's the reality of sloppy implementations that people are often thrown into. You avoid it by 'trust no one' and actually validating with real world data. But like we saw with the DL Monorail.. when dealing with legacy stuff people sometimes are just too trusting of the materials given to them and they build a perfect product that still fails.. perfectly

I agree that those are issues, but they are not insurmountable obstacles to producing a quality product. I have been a software developer for 15 years and I have personally led projects that involved huge data migrations from antiquated systems. I know the ins and outs of such projects. Even if a team includes contractors or offshore developers they don't do their development on 'an island', unsupervised (or they shouldn't). That is what project management and quality assurance are all about. If a developer is not unit testing properly, it should be caught by a code review done by the project management team. Anything not caught by a code review should be caught by quality assurance. If a project is properly managed and goes through all of the steps that should be taken (discovery, design, development, quality assurance, lather, rinse, repeat as necessary), then it should be junk in, good product out regardless of the quality of the existing data structure or the 'sins of our fathers'.

What I am saying is at some step in the process, the project team dropped the ball. It doesn't matter why, it matters that they did. The WDW ADR system is small compared to the data warehouse that will be at the core of NextGen. If they can't get the ADR system right, I don't have much faith in their ability to design and properly implement NextGen without a hitch.

To quote Forest Gump, "That's all I have to say 'bout that."

 

[Disneyhead'71]

Nah.. I just don't see value in jumping off the cliff before there is concrete reason to do so. I'm not losing anything from Disney right now.. no need to slit my wrists or preach the end of the world. If it comes.. I'll be right there criticizing their stupidity. But for now.. what's the rush?

I gave up around 2006. This is the nail in the coffin.

See you in The Keys. Bring a book.

 

[hiptwinmama]

Love this quote from an article I just read on Time Business and Money. It perfectly describes the purpose behind Fast Pass +

Disney doesn’t want guests milling around for hours waiting for their turn to hop aboard a seven-minute ride. When guests are waiting in line, you see, they aren’t in gift shops and restaurants. They aren’t booking spa treatments or sitting down at special meals featuring princesses and other beloved Disney characters. Simply put, when guests are waiting line, they aren’t spending money. Instead, they’re just waiting around, and the wait is probably leaving a bad taste in their mouths. By offering the possibility of skipping lines, Disney decreases the annoyance factor, while simultaneously increasing the odds that guests will do and spend more during visits.​

Read more: http://business.time.com/2013/01/10/why-vacationers-will-soon-spend-even-more-time-and-money-at-disney-world/#ixzz2KmptQRJi​

 

[parker4fm]

Why would that surprise you?

For the record, the Yeti is one of many broken or turned off show scenes on Everest.

Okay ladies and gentlemen, if you're a true Disney fan, you know all about the Yeti. And you know why it cannot be "fixed" the way most of us would want. Here's the deal...the mountain is a separate structure, the coaster support is a separate structure, and the yeti is a separate structure. In order for the full repair to happen the mountain would have to literally be opened! Can you imagine the time and cost involved with this?

Disney just can't do it. Especially in a park that already lacks attractions. Yes, we can all admit that WDI made a major mistake somewhere with this, but they can't risk running the Yeti in full mode and having it shake the support structure of the coaster.

All of that said, the yeti is not worth discussing. It is not broken, it just "is".

 

[parker4fm]

Everest has lost nearly all of its show scene effects.

Yeti out of action.
Mountain top mist out of action.
Upper cave mist out of action.
Summit bird out of action.
Load area steam nearly always out of action.
Waterfalls intermittent.
Landscaping removed and not properly replaced.
Load area track lighting left on.

All of us who are Disney at heart can agree that show quality has gone down hill. The quality control is almost nonexistent. But the same can be said for the entertainment division. MK has not had a new parade or castle show in how many years?

But these are all different departments and different budgets. It's a sad truth.

 

[parker4fm]

Yet another delay announced to cast members in merchandise today about Magic Bands. No specific date available for launch at this time.

 

[xdan0920]

Okay ladies and gentlemen, if you're a true Disney fan, you know all about the Yeti. And you know why it cannot be "fixed" the way most of us would want. Here's the deal...the mountain is a separate structure, the coaster support is a separate structure, and the yeti is a separate structure. In order for the full repair to happen the mountain would have to literally be opened! Can you imagine the time and cost involved with this?

Disney just can't do it. Especially in a park that already lacks attractions. Yes, we can all admit that WDI made a major mistake somewhere with this, but they can't risk running the Yeti in full mode and having it shake the support structure of the coaster.

All of that said, the yeti is not worth discussing. It is not broken, it just "is".

All indications are that this is flat out not true. The Yeti can be fixed. But it won't be.