whats so difficult about merging it? couldn't they just have a field that asks for dci number when you create/update an account - that's pretty basic isn't it?
i mean its a minor thing, but it definitely feels like another in the many small missteps that alienate players and disconnect the company further from them, especially veteran players.
It may be a "minor" thing on the surface but underneath the hood, it's possible that the DCI database is horribly complex. When the original database was born, it very likely had a very small number of tables with a limited amount of interaction across them. But I guarantee that as the years went by, the original developers probably left. New developers came in. Time marched on and some pointy haired boss told those later developers to add a new feature or start tracking something else. They probably looked at the code and the table structure, looked at the clock, and said, "screw it, I'll just add a new table with some new keys and call it done." And that's exactly what they did. Added a new feature without ever actually touching the old code or old database. Then someone else came along looked at those tables , query strings and old code with orders to add a new feature. So instead of changing the table which would likely break old code, they added another table, or two, or three then added more code. Then some feature was obsoleted and that table sat disused but never dropped because dropping that table would break code somewhere else.
So twenty years later, you have a database with dozens upon dozens upon dozens of tables, half of which the programmer has no idea what they're for or why they're there with so much legacy code that they just write they're own functions to do their own thing because they have no idea what a similarly named function actually does and they don't have the time to figure it out because the boss said they have to produce the code by Monday 9AM and it's already 2AM. Oh, and don't forget that they have to fix an entire block of code they wrote 3 years ago on a whim because they read all about refactoring in "Code Complete" Chapter 24 but completely ignored all the commenting requirements because they thought they would never forget what they wrote at 2AM.
So yeah, there are times that a simple box that allows a specific entry can be extremely convoluted and far more complex that it seems on the surface.
This is cute, but it is nonsense.
We can still query the database successfully, even through the customer-facing web API. That means WotC can still query its database on the backend. Therefore they can still extract data from it to populate the new architecture with legacy customer data.
(I teach database design and I right now in the private sector I am transferring legacy content to a new database architecture)
You assume all businesses maintain ideal database architecture and content? You also assume that their existing programmers can actually untangle what previous programmers actually did? It must be nice but such ideals do not exist whole hog across all companies. It's something to always strive for, sure. But it's hardly a reality for everyone.
Heck no. I'm actually working for a Fortune 500 company whose name you'd recognize and I prepare weekly financial statements in freaking Excel because our current database is horribad, hence why we're upgrading. And our existing programmers cannot actually untangle what previous programmers did, and our enterprise is much larger than WotC.
You need to either improve your assumption making skill, or reduce your assumption making predilection.
The evidence remains the fact that the data is accessible. Therefore...(wait for it) the data is accessible. The data therefore can be reinstalled into whatever superior architecture they're migrating to. They're just of the opinion that the effort isn't worth the value. That is literally all there is to it. My estimate (and remember, I do this, I teach this, and I write textbooks on this) is that if it costs them $5,000 in Seattle-area wages for the person-hours of labor this migration would take, then they're easily overpaying. So. They're ditching all of this data on their oldest customers to save a pretty insubstantial amount of money on an enterprise scale.
whats so difficult about merging it? couldn't they just have a field that asks for dci number when you create/update an account - that's pretty basic isn't it?
i mean its a minor thing, but it definitely feels like another in the many small missteps that alienate players and disconnect the company further from them, especially veteran players.
It may be a "minor" thing on the surface but underneath the hood, it's possible that the DCI database is horribly complex. When the original database was born, it very likely had a very small number of tables with a limited amount of interaction across them. But I guarantee that as the years went by, the original developers probably left. New developers came in. Time marched on and some pointy haired boss told those later developers to add a new feature or start tracking something else. They probably looked at the code and the table structure, looked at the clock, and said, "screw it, I'll just add a new table with some new keys and call it done." And that's exactly what they did. Added a new feature without ever actually touching the old code or old database. Then someone else came along looked at those tables , query strings and old code with orders to add a new feature. So instead of changing the table which would likely break old code, they added another table, or two, or three then added more code. Then some feature was obsoleted and that table sat disused but never dropped because dropping that table would break code somewhere else.
So twenty years later, you have a database with dozens upon dozens upon dozens of tables, half of which the programmer has no idea what they're for or why they're there with so much legacy code that they just write they're own functions to do their own thing because they have no idea what a similarly named function actually does and they don't have the time to figure it out because the boss said they have to produce the code by Monday 9AM and it's already 2AM. Oh, and don't forget that they have to fix an entire block of code they wrote 3 years ago on a whim because they read all about refactoring in "Code Complete" Chapter 24 but completely ignored all the commenting requirements because they thought they would never forget what they wrote at 2AM.
So yeah, there are times that a simple box that allows a specific entry can be extremely convoluted and far more complex that it seems on the surface.
This is cute, but it is nonsense.
We can still query the database successfully, even through the customer-facing web API. That means WotC can still query its database on the backend. Therefore they can still extract data from it to populate the new architecture with legacy customer data.
(I teach database design and I right now in the private sector I am transferring legacy content to a new database architecture)
Nobody's complaining about the need for a new database.
The issue is that customer history is being lost by not merging old Cust_ID's into the new system.
That's just incredibly lazy transition management and bad business practice and WotC deserves to have the egg on their tie pointed at with blinking neon lights.
Heck no. I'm actually working for a Fortune 500 company whose name you'd recognize and I prepare weekly financial statements in freaking Excel because our current database is horribad, hence why we're upgrading. And our existing programmers cannot actually untangle what previous programmers did, and our enterprise is much larger than WotC.
You need to either improve your assumption making skill, or reduce your assumption making predilection.
The evidence remains the fact that the data is accessible. Therefore...(wait for it) the data is accessible. The data therefore can be reinstalled into whatever superior architecture they're migrating to. They're just of the opinion that the effort isn't worth the value. That is literally all there is to it. My estimate (and remember, I do this, I teach this, and I write textbooks on this) is that if it costs them $5,000 in Seattle-area wages for the person-hours of labor this migration would take, then they're easily overpaying. So. They're ditching all of this data on their oldest customers to save a pretty insubstantial amount of money on an enterprise scale.
This is cute, but it is nonsense.
We can still query the database successfully, even through the customer-facing web API. That means WotC can still query its database on the backend. Therefore they can still extract data from it to populate the new architecture with legacy customer data.
(I teach database design and I right now in the private sector I am transferring legacy content to a new database architecture)
Nobody's complaining about the need for a new database.
The issue is that customer history is being lost by not merging old Cust_ID's into the new system.
That's just incredibly lazy transition management and bad business practice and WotC deserves to have the egg on their tie pointed at with blinking neon lights.
Little to zero actual systemic benefit? check.
Brilliant.