@Alex Papadimoulis said:
Honestly. A company with that many customers cannot have managers that incompetent.
I submit that you do not have an open mind =).
@Alex Papadimoulis said:
You don't change your entire business
model to rememedy a mistake a few postcards would solve. That's like
spilling a drop of paint on the carpet and deciding to paint the entire
carpet to match.
How is this a change to the entire business model? From the point
of view of every department except development, this change is
imperceptible. There were essentially zero business processes
that needed to change, because customer service already asked for the
person's last name for verification purposes.
In some companies the public admission of a company's mistake is
anathema, to be avoided at all costs. If development can wave
that wand and make the problem go away, the management would jump on it
every time.
@Alex Papadimoulis said:
Secondly, relying on the uniquness of a
last names across a million customers would be a total disaster.
You misunderstand. It was not relying solely on the last name,
since it included the previously unique customer codes as well.
New customer codes were indeed generated in the same manner that they
always had been.
@Alex Papadimoulis said:
And finally, what of the application?
How possibly could a system that handles millions of customers be
architected that all that is required to change is a UNIQUE
constraint? Just on a very basic app (certainly not one for
millions of customers), you'd need to change the UI (where they input
Cust#), the middle tier classes ( GetCustomerByCode, etc), the database
Stored Procedurs which assume only one cust/code.
ROFL. I wish the application had a middle-tier. Your
estimation ability is bedazzled by the number of customers and is not
anywhere grounded in reality.
You're right that the UI needed to change -- the app detected the
unique constraint violation and said 'hey, duplicate customer
code'. This needed to be changed to include the new constraint
information, of course. But that was purely informational and
wasn't critical to the day's operations.
No stored procedures assumed only one customer code! Like I said,
everything db-side used the identity column. The customer code
was used for display and user search purposes only. Development
could hardly care that it existed.
@Alex Papadimoulis said:
I call bullshit. No way this happened in a company of the size you described.
Hahaha, so what size company did I describe? How many millions a
year do you think this company makes? And how many millions of
customers were in the database? I'd love to hear your guesses.
The only parts of my anecdote you find unbelievable were either
factual misunderstandings or completely subjective guesses.