3 ms·
I can only attest, configuration bloat is especially relevant to complex enterprise products, for obvious reasons. What we normally do in our products is to pro
by rodionos 10y ago
I can only attest, configuration bloat is especially relevant to complex enterprise products, for obvious reasons. What we normally do in our products is to provide a simple interface to view a filtered list of non-default settings. We also have a way to export this list of custom setting names (not values), so we can query our customer base once in a while, to check which settings are not utilized. We've used this trick to internalize or EOL a lot of "knobs" that haven't been used at all.
- mrweasel 10y ago>configuration bloat is especially relevant to complex enterprise products, for obvious reasons I've always assumes that enterprise software has complex configuration options because it's more bespoke than the supplier would have you believe. So rather than delivering a piece of software tailored to the need of one, or a few customers, the new behaviour just becomes a setting in a much, much larger system. The goal being having just one code base.
- joshyeager 10y agoOur product is on the small side of "enterprise". We have many configuration options that are customer-driven, but we're not trying to replace bespoke software. For example, we have 5-6 different settings for password policy. Most customers use the defaults, but the ones in banking and government usually have very specific security rules that require them to tweak the settings. One allows 10-char passwords but requires them to expire in 60 days. Another is 12 characters and 90 days. And so on.
- rodionos 10y agoWe had that too. At some point we added LDAP authentication and it took care of user credential management. LDAP (AD) is universally present in the enterprise.