4 ms·

What do you do when one customer wants to deviate from the way the product works, and you can't say no? Do you say: if (customerID = 328281) { ...

What do you do when one customer wants to deviate from the way the product works, and you can't say no? Do you say: if (customerID = 328281) { ... } else { ... } Or do you go ahead and build the architecture that lets you specify which class or method to run per customer? The situation does come up often enough to have to make a decision. I'm working on a project which has tended to say "if (customerID = ..." in the past, but I decided to move to the more configurable/pluggable approach. I'm actually not sure if I made the right decision.

brlewis 16y ago
You did exactly the right thing: made the pluggable architecture after you got proof it would be useful.
ldh 16y ago
I recall working on one project where those customer-specific exceptions became the rule, and the core business logic was pretty well obfuscated by the time I got there. If your project makes one exception, a whole bunch more are likely to follow.
snorkel 16y ago
Here's my take: 0 customers asked for it: Don't abstract it. 1 customer asked for it: Corner-case it. 2 customers asked for it: Strategy pattern. 3 customers asked for variations: Config option.
- KirinDave 16y ago
  This is not a bad plan, but there is a danger here. If you find that "1 customer" (being a series of disparate customers) all ask for various minor tweaks to the way something works, then before you have half-a-dozen disparate forks in your logic you probably do want to pull that out and use a strategy pattern where applicable. It doesn't take many clever sidesteps in a clean algorithm to make a nightmarish scenario later on.
- jacquesm 16y ago
  I'd roll 1 and 2 together, typically if one customer asks for it today another one will ask for it next week. Save yourself the time and bother to dig back in again and solve it at least for the foreseeable future with less overhead than what it would take to tackle the same task again, typically getting in to do the job takes at least as long as doing the job in situations like that (just to make sure you didn't break anything by accident, test the works and so on). If the overhead is constant and a 'small' fix like that takes 5 instead of 4 hours including all the extras then that's a trade-off worth making. Unless of course you're really under pressure.
- KaeseEs 16y ago
  Something I've wondered for a while: how does the strategy pattern differ from just passing a function pointer?
  - Deestan 16y ago
    > how does the strategy pattern differ from just passing a function pointer? It's just a verbose way to perform the same abstraction. Use it only if function pointers are unavailable or considered unsafe in your programming language.
  - Raphael_Amiard 16y ago
    There are a bunch of patterns that simply disappear, or are greatly simplified when you have first class functions in your language, namely, observer, strategy, visitor, and a bunch of others i can't remember right now
jonpaul 16y ago
My take: I realize that this is seemingly dodging the question. But you tell the customer 'no.' Seriously. ldh [http://news.ycombinator.com/item?id=2143654 http://news.ycombinator.com/item?id=2143654] makes a great point, if you make one exception, many are to follow. Soon your code will be littered with these special cases for customers and will become an unmaintainable message. Listen to 37Signals when they say that it's OK for your customers to outgrow your software. http://37signals.com/svn/archives2/growing_in_vs_growing_out.php http://37signals.com/svn/archives2/growing_in_vs_growing_out...

brlewis 16y ago

You did exactly the right thing: made the pluggable architecture after you got proof it would be useful.

ldh 16y ago

I recall working on one project where those customer-specific exceptions became the rule, and the core business logic was pretty well obfuscated by the time I got there. If your project makes one exception, a whole bunch more are likely to follow.

snorkel 16y ago

Here's my take: 0 customers asked for it: Don't abstract it. 1 customer asked for it: Corner-case it. 2 customers asked for it: Strategy pattern. 3 customers asked for variations: Config option.

KirinDave 16y ago
This is not a bad plan, but there is a danger here. If you find that "1 customer" (being a series of disparate customers) all ask for various minor tweaks to the way something works, then before you have half-a-dozen disparate forks in your logic you probably do want to pull that out and use a strategy pattern where applicable. It doesn't take many clever sidesteps in a clean algorithm to make a nightmarish scenario later on.
jacquesm 16y ago
I'd roll 1 and 2 together, typically if one customer asks for it today another one will ask for it next week. Save yourself the time and bother to dig back in again and solve it at least for the foreseeable future with less overhead than what it would take to tackle the same task again, typically getting in to do the job takes at least as long as doing the job in situations like that (just to make sure you didn't break anything by accident, test the works and so on). If the overhead is constant and a 'small' fix like that takes 5 instead of 4 hours including all the extras then that's a trade-off worth making. Unless of course you're really under pressure.
KaeseEs 16y ago
Something I've wondered for a while: how does the strategy pattern differ from just passing a function pointer?
- Deestan 16y ago
  > how does the strategy pattern differ from just passing a function pointer? It's just a verbose way to perform the same abstraction. Use it only if function pointers are unavailable or considered unsafe in your programming language.
- Raphael_Amiard 16y ago
  There are a bunch of patterns that simply disappear, or are greatly simplified when you have first class functions in your language, namely, observer, strategy, visitor, and a bunch of others i can't remember right now

jonpaul 16y ago

My take: I realize that this is seemingly dodging the question. But you tell the customer 'no.' Seriously. ldh [http://news.ycombinator.com/item?id=2143654 http://news.ycombinator.com/item?id=2143654] makes a great point, if you make one exception, many are to follow. Soon your code will be littered with these special cases for customers and will become an unmaintainable message. Listen to 37Signals when they say that it's OK for your customers to outgrow your software. http://37signals.com/svn/archives2/growing_in_vs_growing_out.php http://37signals.com/svn/archives2/growing_in_vs_growing_out...