Hacker News Reader

Comment by jcromartie | Hacker News Reader

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.

View on HN

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.

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.

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.

Something I've wondered for a while: how does the strategy pattern differ from just passing a function pointer?

> 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.

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

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

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.

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] 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...

Reply on news.ycombinator.com