Carfield,

I have experience with a product that has seven customers, each of which has
quite a bit of custom logic in addition to the common code. We have a single
binary that is run for all the customers. All the customer-specific
decisions are defered until run-time. The challenge is making sure that no
customer-specific code is executed for a different customer, but our design
(as it has evolved) makes this unlikely.

I contrast this with a similar scale project I worked on briefly that had
seven different code bases for seven customers. Each time a new customer was
signed, the "freshest" code base was cloned and thereafter all changes had
to be merged, potentially, six times. The company was sinking under the
weight of merging.

The key difference between the two is finding ways to defer binding. What I
found was that this began by choosing a principle--we are going to have a
single code base. This eliminated some design options, but plenty still
remained. Another important principle is that in the first case we don't
mind having some duplicate code. If it's clear how to eliminate duplication,
we do, but we are willing to wait for clarity.

Does this seem to apply to your situation? Are there ways you could defer
binding and reduce the build-time complexity?

Regards,

Kent Beck
Three Rivers Institute

_____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Carfield Yim
Sent: Thursday, April 17, 2008 5:36 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] Re: What do you think about parallel releases in a single
project?



> I am not sure what you mean by "multiple software support difference
> markets" but my guess is that no, we are not engaged in that kind of a
> project.
>

For example for a stock trading system to support difference exchange,
like HK, TW, KR, difference software need to support difference
features, which are similar but not same.

In theory we can still do what you've mentioned but it is difficult
because developers for difference region don't know the requirement of
other exchange. I just wonder if anyone have experience of maintain
software like this in single trunk, we were try to do that before but
the result is not good.





[Non-text portions of this message have been removed]