Timeline for How can we avoid extremely complex configurations in enterprise software?
Current License: CC BY-SA 4.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 21, 2023 at 11:33 | history | edited | Doc Brown | CC BY-SA 4.0 |
deleted 10 characters in body
|
| Oct 21, 2023 at 11:35 | comment | added | Doc Brown | @raznagul: you said your suggested alternative is "separate implementations". So I can assume the responsibility for customer specific business rules is in your case at the vendor's side, otherwise you would not see that as a real alternative, right? Hence, the business rules are maintained by you, the software vendor, but in a rule engine with scripts, and not by the customer themselves, am I also correct? Then why on earth don't you put the script file or rule files under source control? | |
| Oct 21, 2023 at 11:30 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 38 characters in body
|
| Oct 21, 2023 at 11:16 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 347 characters in body
|
| Oct 21, 2023 at 6:02 | comment | added | raznagul | I currently work on a product that has a rule engine with script support. There are a lot of problems which could be summarized as 'business logic not under source control'. Also as developers usually also are 3rd lvl support, I wouldn't be supprised if havinging separate implementations for each client would be less work over all. | |
| Oct 20, 2023 at 12:02 | comment | added | Doc Brown | @MatthieuM.: I would not call this "pushing back on requirements", only "discussing alternative solutions with the customers which require less configuration switches". Still I think you draw attention to an important point: I have often seen devs adding switches or optiones because they simply were unsure what the customer really needs because the requirements were not well understood. So getting a firm understanding of the requirements and processes of the customer can help avoiding unneccessary config parameters. | |
| Oct 20, 2023 at 7:13 | comment | added | Matthieu M. | One thing missing from this list... is pushing back on "requirements". Most customers will try (emphasis on try) to match their real requirements to your software, and propose solutions for you to implement... but they do not quite know your software, so often their "solutions" boil down to bolting on whatever workflow they know without considering whether it fits (hint: it doesn't). It's important to push back here. Get back to the actual problems to solve -- not the current strategies they use to solve them -- and work your way toward a solution from there. Been there, done that... | |
| Oct 20, 2023 at 4:42 | comment | added | Doc Brown | @gaazkam: as I wrote: when you have only 3 requested variants (as in your comment), its probably best using individual implementations per customer. When you have 10-20, it starts to make sense to refactor commonalities out, which leads to few parameters. And when you have more variants, you might switch to "a customer-editable scripting language", which is a form of complex configuration - externalized business logic which requires a specialist. | |
| Oct 20, 2023 at 4:35 | comment | added | gaazkam |
Hmm, actually why make attachSupplementalDocuments dry? Wouldn't it make perfect sense to have, separately, attachSupplementalDocumentsCustomer1, attachSupplementalDocumentsClient2, etc, plus one attachSupplementalDocumentsDefault? Even if there is some overlap between the code of these functions? Also perhaps attachSupplementalDocuments could be a good candidate to be implemented in some scripting language, so that we have the best of both worlds: the client can modify it themselves but the logic still resides in code, not configuration?
|
|
| Oct 19, 2023 at 18:45 | comment | added | Bergi | "try to make configuration options as independent from each other as possible, so changing one does not affect the others." - and when that is not doable, choose the data structure for the configuration wisely, so that incompatible settings cannot even be represented. | |
| Oct 19, 2023 at 14:43 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 37 characters in body
|
| Oct 19, 2023 at 12:10 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 520 characters in body
|
| Oct 19, 2023 at 11:46 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 393 characters in body
|
| Oct 19, 2023 at 11:39 | comment | added | Doc Brown | ... what finally helps to keep this manageable then is to add some configuration editor with a well designed UI , one which makes changing the rules and parameters simple and fearless, one which explains the parameters well and validates their consistency. That is also a strategy to deal with the issue. (3/3) | |
| Oct 19, 2023 at 11:34 | comment | added | Doc Brown |
... requirements of all 10 customers without implementing 10 variants of the same function. The parameters will become part of the external configuration. Now imagine you have 100 customers, and they can all have different rules for attaching supplemental documents, and those rules change regularly - then it is probably best to let them manage the rules by themselves, and implementing attachSupplementalDocuments as a small rule interpreter is quite justified. (2/3)
|
|
| Oct 19, 2023 at 11:29 | comment | added | Doc Brown |
@gaazkam: and in regards to the "Daily WTF": There is some wisdom in the article, but the truth is somewhere in the middle. Lets say you have two customers, one needs the shown attachSupplementalDocuments, the other one does not need it. Then just make a configuration rule to switch the call to it on or off - still the function can keep all its literals. Now lets imagine you have 10 customers, and each one has different rules how to attach supplemental documents. For keeping the code DRY, you start to add parameters to attachSupplementalDocuments, so you can fulfill all business ... (1/3)
|
|
| Oct 19, 2023 at 11:20 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 84 characters in body
|
| Oct 19, 2023 at 10:59 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 1050 characters in body
|
| Oct 19, 2023 at 9:12 | comment | added | Doc Brown | @gaazkam: the problem with using compile time switches is it does not scale well with increasing n. Note the number of required internal, orthogonal feature switches is usually way larger than "n". Try to test every deployment, every weekly update, with n differently compiled products - good luck. | |
| Oct 19, 2023 at 7:20 | comment | added | gaazkam | I still don't fully understand why it is necessary to customize the product at runtime rather than compile time. If it appears that we have n customers and are, in fact, selling n different products, then why not embrace that we are actually developing n applications, rather than maintain the illusion that there is only one product? And in SW engineering the typical solution to having n applications, different enough to make them separate, yet similar enough to share a lot under the hood is to extract this similarity into a common module, while still compiling these as separate apps? | |
| Oct 19, 2023 at 7:14 | comment | added | gaazkam | So, I guess the answer is that, even if there is SOME wisdom to that The Daily WTF article, it is in general NOT true what it claims, namely that business rules always belong in code and never in configuration? To the contrary, sometimes it is necessary to store busines rules in configuratin? | |
| Oct 18, 2023 at 20:45 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 539 characters in body
|
| Oct 18, 2023 at 20:32 | history | answered | Doc Brown | CC BY-SA 4.0 |