Return to Answer

In my experience, the most important factor here is not necessarily a technically one, but an organizational: the number of teams and developers who are available for the maintenance of such a system.

• In case there is only one small team who has to serve several customers, keeping the code as DRY as possible should be the top goal. Avoiding copy-paste programming as much as possible helps to keep the team out of maintenance hell in the long run. Fortunately, OOP, functional programming, and other techniques have equipped us with more tools than just if-else orgies to make certain code configurable.

• In case there are different teams, maybe one which takes the responsibility for the core project and customer X, another one for variants/forks for customer Y and Z, having each team maintaining different code variants of the same module is much more acceptable than for a single team (and sometimes, it is even more desirable, since it can reduce the communication overhead between the teams and the need to invest effort into integrating different, conflicting customer wishes).

Of course, the former is a simplification. Even for a small team, it can sometimes make sense to copy a certain module and create customer-specific variants - it depends heavily on the individual set of requirements for the module. And even when there are multiple teams, it will make sense to keep certain core modules general and configurable, so they can be reused in an unmodified fashion for several different customers.

For both cases, the key point is to separate code and modules which may be customer specific from the modules which should stay general and common for all customers, and that is the real software engineering challenge. This is where things like separation-of-concerns, the strategy pattern, dependency injection, data-driven programming or domain-specific languages (and a few other techniques) shine. They can all help to move the customer-specific parts of a program into a central place, and the common code in clearly separated modules.

Is there empirical evidence for this? Sure, look at all the forks of different Open Source projects - wherever one produces such a fork of a "living" project, they are effectively copying the code and maintaining the code as a new team, with the goal of making a variant for a new user group ("customer"). This happens regularly from the smallest projects up to the largest ones (for example, look at the dozens of different Linux distributions and their responsible teams, this is probably one of the most prominent examples). Though those teams are clearly violating the DRY principle to some degree, it does not necessarily cause big maintenance issues, at least not issues which cannot be handled by a professional team.

Let me add a few words about your specific case: a program which can be used in a multi-user mode connecting to a client-server DB can surely be used by a single person, too - I don't see a striking reason why this should be split into two different programs. Moreover, there will be not many "if-else" checks necessary in the code base. Instead, it should be possible to implement such a program in terms of N users, where N=1 isn't treated differently from N>1. One may want to use a more lightweight database backend for a single person, and to provide two different database layers, and maybe there are some optimizations possible in single-user mode. Still I don't see how it could make sense for a two person team to duplicate the program and maintain a lot of duplicate code.

In my experience, the most important factor here is not necessarily a technically one, but an organizational: the number of teams and developers who are available for the maintenance of such a system.

• In case there is only one small team who has to serve several customers, keeping the code as DRY as possible should be the top goal. Avoiding copy-paste programming as much as possible helps to keep the team out of maintenance hell in the long run. Fortunately, OOP, functional programming, and other techniques have equipped us with more tools than just if-else orgies to make certain code configurable.

• In case there are different teams, maybe one which takes the responsibility for the core project and customer X, another one for variants/forks for customer Y and Z, having each team maintaining different code variants of the same module is much more acceptable than for a single team (and sometimes, it is even more desirable, since it can reduce the communication overhead between the teams and the need to invest effort into integrating different, conflicting customer wishes).

Of course, the former is a simplification. Even for a small team, it can sometimes make sense to copy a certain module and create customer-specific variants - it depends heavily on the individual set of requirements for the module. And even when there are multiple teams, it will make sense to keep certain core modules general and configurable, so they can be reused in an unmodified fashion for several different customers.

For both cases, the key point is to separate code and modules which may be customer specific from the modules which should stay general and common for all customers. That is the real software engineering challenge. This is where things like separation-of-concerns, the strategy pattern, dependency injection, data-driven programming or domain-specific languages (and a few other techniques) shine. They can all help to isolate the customer-specific parts of a program, and the smaller that isolated part becomes, the easier it is to maintain code for different customers with a small team.

Is there empirical evidence for this? Sure, look at all the forks of different Open Source projects - wherever one produces such a fork of a "living" project, they are effectively copying the code and maintaining the code as a new team, with the goal of making a variant for a new user group ("customer"). This happens regularly from the smallest projects up to the largest ones (for example, look at the dozens of different Linux distributions and their responsible teams, this is probably one of the most prominent examples). Though those teams are clearly violating the DRY principle to some degree, it does not necessarily cause big maintenance issues, at least not issues which cannot be handled by a professional team.

Let me add a few words about your specific case: a program which can be used in a multi-user mode connecting to a client-server DB can surely be used by a single person, too - I don't see a striking reason why this should be split into two different programs. Moreover, there will be not many "if-else" checks necessary in the code base. Instead, it should be possible to implement such a program in terms of N users, where N=1 isn't treated differently from N>1. One may want to use a more lightweight database backend for a single person, and to provide two different database layers, and maybe there are some optimizations possible in single-user mode. Still I don't see how it could make sense for a two person team to duplicate the program and maintain a lot of duplicate code.

In my experience, the most important factor here is not necessarily a technically one, but an organizational: the number of teams and developers who are available for the maintenance of such a system.

• In case there is only one small team who has to serve several customers, keeping the code as DRY as possible should be the top goal. Avoiding copy-paste programming as much as possible helps to keep the team out of maintenance hell in the long run. Fortunately, OOP, functional programming, and other techniques have equipped us with more tools than just if-else orgies to make certain code configurable.

• In case there there are different teams, maybe one responsible for the core project and customer X, one for variants required for customer Y and Z, having each team maintaining different variants of the same module is much more acceptable than for a single team (and sometimes, it is even more desirable, since it can reduce the communication overhead between the teams and the need to invest effort into integrating different, conflicting customer wishes).

Of course, the former is a simplification. Even for a small team, it can sometimes make sense to copy a certain module and create customer-specific variants - it depends heavily on the individual set of requirements for the module. And even when there are multiple teams, it will make sense to keep certain core modules general and configurable, so they can be reused in an unmodified fashion for several different customers.

For both cases, the key point is to separate code and modules which may be customer specific from the code which should stay general, and that is the real software engineering challenge. This is where things like separation-of-concerns, the strategy pattern, dependency injection, data-driven programming or domain-specific languages (and a few other techniques) shine. They cam all help to move the customer-specific parts of a program into a central place, keeping most of the code general.

Is there empirical evidence for this? Sure, look at all the forks of different Open Source projects - wherever one produces such a fork of a "living" project, they are effectively copying the code and maintaining the code as a new team, with the goal of making a variant for a new user group ("customer"). This happens regularly from the smallest projects up to the largest ones (look at the the tons of different Linux distributions and their responsible teams, this is probably one of the most prominent examples). Though those teams are clearly violating the DRY principle to some degree, it does not necessarily cause big maintenance issues, at least not issues which cannot be handled by a professional team.

Let me add a few words about your specific case: a program which can be used in a multi-user mode connecting to a client-server DB can surely be used by a single person, too - I don't see a striking reason why this should be two different programs. Moreover, there will be not many "if-else" checks necessary in the code base. It should be possible to implement such a program in terms of N users, where N=1 isn't treated differently from N>1. One may want to use a more lightweight database backend for a single person, and to provide two different database layers, and maybe there are some optimizations possible in single-user mode. Still I don't see how it could make sense for a two person team to duplicate the program and maintain a lot of duplicate code.

In my experience, the most important factor here is not necessarily a technically one, but an organizational: the number of teams and developers who are available for the maintenance of such a system.

• In case there is only one small team who has to serve several customers, keeping the code as DRY as possible should be the top goal. Avoiding copy-paste programming as much as possible helps to keep the team out of maintenance hell in the long run. Fortunately, OOP, functional programming, and other techniques have equipped us with more tools than just if-else orgies to make certain code configurable.

• In case there are different teams, maybe one which takes the responsibility for the core project and customer X, another one for variants/forks for customer Y and Z, having each team maintaining different code variants of the same module is much more acceptable than for a single team (and sometimes, it is even more desirable, since it can reduce the communication overhead between the teams and the need to invest effort into integrating different, conflicting customer wishes).

Of course, the former is a simplification. Even for a small team, it can sometimes make sense to copy a certain module and create customer-specific variants - it depends heavily on the individual set of requirements for the module. And even when there are multiple teams, it will make sense to keep certain core modules general and configurable, so they can be reused in an unmodified fashion for several different customers.

For both cases, the key point is to separate code and modules which may be customer specific from the modules which should stay general and common for all customers, and that is the real software engineering challenge. This is where things like separation-of-concerns, the strategy pattern, dependency injection, data-driven programming or domain-specific languages (and a few other techniques) shine. They can all help to move the customer-specific parts of a program into a central place, and the common code in clearly separated modules.

Is there empirical evidence for this? Sure, look at all the forks of different Open Source projects - wherever one produces such a fork of a "living" project, they are effectively copying the code and maintaining the code as a new team, with the goal of making a variant for a new user group ("customer"). This happens regularly from the smallest projects up to the largest ones (for example, look at the dozens of different Linux distributions and their responsible teams, this is probably one of the most prominent examples). Though those teams are clearly violating the DRY principle to some degree, it does not necessarily cause big maintenance issues, at least not issues which cannot be handled by a professional team.

Let me add a few words about your specific case: a program which can be used in a multi-user mode connecting to a client-server DB can surely be used by a single person, too - I don't see a striking reason why this should be split into two different programs. Moreover, there will be not many "if-else" checks necessary in the code base. Instead, it should be possible to implement such a program in terms of N users, where N=1 isn't treated differently from N>1. One may want to use a more lightweight database backend for a single person, and to provide two different database layers, and maybe there are some optimizations possible in single-user mode. Still I don't see how it could make sense for a two person team to duplicate the program and maintain a lot of duplicate code.

In my experience, the most important factor here is not necessarily a technically one, but an organizational: the number of teams and developers who are available for the maintenance of such a system.

• In case there is only one small team who has to serve several customers, keeping the code as DRY as possible should be the top goal. Avoiding copy-paste programming as much as possible helps to keep the team out of maintenance hell in the long run. Fortunately, OOP, functional programming, and other techniques have equipped us with more tools than just if-else orgies to make certain code configurable.

• In case there there are different teams, maybe one responsible for the core project and customer X, one for variants required for customer Y and Z, having each team maintaining different variants of the same module is much more acceptable than for a single team (and sometimes, it is even more desirable, since it can reduce the communication overhead between the teams and the need to invest effort into integrating different, conflicting customer wishes).

Of course, the former is a simplification. Even for a small team, it can sometimes make sense to copy a certain module and create customer-specific variants - it depends heavily on the individual set of requirements for the module. And even when there are multiple teams, it will make sense to keep certain core modules general and configurable, so they can be reused in an unmodified fashion for several different customers.

For both cases, the key point is to separate code and modules which may be customer specific from the code which should stay general, and that is the real software engineering challenge. This is where things like separation-of-concerns, the strategy pattern, dependency injection, data-driven programming or domain-specific languages (and a few other techniques) shine. They cam all help to move the customer-specific parts of a program into a central place, keeping most of the code general.

Is there empirical evidence for this? Sure, look at all the forks of different Open Source projects - wherever one produces such a fork of a "living" project, they are effectively copying the code and maintaining the code as a new team, with the goal of making a variant for a new user group ("customer"). This happens regularly from the smallest projects up to the largest ones (look at the the tons of different Linux distributions and their responsible teams, this is probably one of the most prominent examples). Though those teams are clearly violating the DRY principle to some degree, it does not necessarily cause big maintenance issues, at least not issues which cannot be handled by a professional team.

In my experience, the most important factor here is not necessarily a technically one, but an organizational: the number of teams and developers who are available for the maintenance of such a system.

• In case there is only one small team who has to serve several customers, keeping the code as DRY as possible should be the top goal. Avoiding copy-paste programming as much as possible helps to keep the team out of maintenance hell in the long run. Fortunately, OOP, functional programming, and other techniques have equipped us with more tools than just if-else orgies to make certain code configurable.

• In case there there are different teams, maybe one responsible for the core project and customer X, one for variants required for customer Y and Z, having each team maintaining different variants of the same module is much more acceptable than for a single team (and sometimes, it is even more desirable, since it can reduce the communication overhead between the teams and the need to invest effort into integrating different, conflicting customer wishes).

Of course, the former is a simplification. Even for a small team, it can sometimes make sense to copy a certain module and create customer-specific variants - it depends heavily on the individual set of requirements for the module. And even when there are multiple teams, it will make sense to keep certain core modules general and configurable, so they can be reused in an unmodified fashion for several different customers.

For both cases, the key point is to separate code and modules which may be customer specific from the code which should stay general, and that is the real software engineering challenge. This is where things like separation-of-concerns, the strategy pattern, dependency injection, data-driven programming or domain-specific languages (and a few other techniques) shine. They cam all help to move the customer-specific parts of a program into a central place, keeping most of the code general.

Is there empirical evidence for this? Sure, look at all the forks of different Open Source projects - wherever one produces such a fork of a "living" project, they are effectively copying the code and maintaining the code as a new team, with the goal of making a variant for a new user group ("customer"). This happens regularly from the smallest projects up to the largest ones (look at the the tons of different Linux distributions and their responsible teams, this is probably one of the most prominent examples). Though those teams are clearly violating the DRY principle to some degree, it does not necessarily cause big maintenance issues, at least not issues which cannot be handled by a professional team.

Let me add a few words about your specific case: a program which can be used in a multi-user mode connecting to a client-server DB can surely be used by a single person, too - I don't see a striking reason why this should be two different programs. Moreover, there will be not many "if-else" checks necessary in the code base. It should be possible to implement such a program in terms of N users, where N=1 isn't treated differently from N>1. One may want to use a more lightweight database backend for a single person, and to provide two different database layers, and maybe there are some optimizations possible in single-user mode. Still I don't see how it could make sense for a two person team to duplicate the program and maintain a lot of duplicate code.