[emodendroket]

"Reconciling" the data isn't my job; the user can use the custom fields for whatever they want.

It's certainly true that life is easier if you never implement certain kinds of features but at that rate why make a program at all?

[mason55]

> "Reconciling" the data isn't my job; the user can use the custom fields for whatever they want.

I disagree strongly here and see this attitude a lot. It's easy to say "not my problem, you fucked it up, you fix it" but that is a very customer-hostile attitude.

Instead we should be giving users functionality they want in a way that prevents them from screwing things up through a combination of feedback and constraints. Sure, if a user types in blatantly incorrect data there's not much you can do. But you can do a lot more than say "here's a narrow ledge and a pit of snakes, if you fall in it's not my fault". This just results in unhappy customers who don't care whose fault it is, all they know is that your software ate their data.

[mgkimsal]

> I disagree strongly here and see this attitude a lot. It's easy to say "not my problem, you fucked it up, you fix it" but that is a very customer-hostile attitude.

Very in agreement here. Almost without fail, if they knew enough how to 'fix' it, they wouldn't have fucked it up in the first place.

Much of this attitude depends on org structure. Are you talking about paying end-customers? Or joe in accounting 3 doors down who consistently never follows any directions you give him re: data?

[emodendroket]

I mean, I realize this discussion is abstract, but I can't think of a lot of ways I could possibly enforce normalization on data when I don't even control what the fields are.