I am responsible for a b2b system with a few dozen per-client settings, many of which are old and have defaults. For instance, there is the grace period, which allows a limited self-service time window for clients to enter data that was missed during the normal course of business. It seemed like a good idea at the time, but now we have a set of invisible values hidden in code holding those defaults. And we can’t change them.
The main problem is, changing a default is an operational change to an unknown scope of clients. On top of that, there could be clients that have the current default explicitly configured: would we want to change them, too? It probably loops in the CEO and takes at least a week of meetings to answer that.
From a b2b business standpoint, it is actually better to require a configuration value (and let the support team view/modify it), even if it introduces the possibility of failure. Our clients will use the normal support channel (well-oiled and always staffed) to raise the error message to us, if tech doesn’t proactively alert themselves about it.
For an ecommerce or public website where users would just leave, it’s probably more costly to “crash on error” than it is to let an errant process continue. But if management prefers to halt and catch fire, the defaults are the opposite of that.
No comments:
Post a Comment