Return to Answer

If people start reasoning about design with the words "if tomorrow", this is often a big warning sign for me, at least if the decision includes extra work and effort for which noone really knows if this will ever pay off.

Duplication of code reduces the effort only for a short term, but it will increase the maintainance efforts almost immediately, proportional to the number of duplicated lines of code. Note also that once code is duplicated, it will become hard to remove the duplication when it turns out this was the wrong decision, whilst it is still easy to introduce duplication later if it turns out sticking to DRY was the wrong decision.

Said that, in larger organizations, it is sometimes beneficial to favor independency of different teams over the DRY principle. If removing the duplication by extracting the 95% common parts of the APIs two a new component leads to a coupling of two otherwise independent teams, this might not be the wisest decision. On the other hand, if you have limited resources and there will be only one team maintaining both APIs, I am sure it will be in their own interest not to create any double effort and avoid any unnecessary code duplication.

Note further it makes a difference if "Home" and "Agency" APIs are used by fully different applications exclusively, or if one might try to write a component build on top of those APIs which can be used in a "Home" context as well as in an "Agency" context. For this situation, having the common parts of the APIs exactly identical (which you can only guarantee if the common parts are not duplicated), will make the development of such a component probably much easier.

If people start reasoning about design with the words "if tomorrow", this is often a big warning sign for me, especially when the argument is used to justify a decision which includes extra work and effort, for which noone really knows if this will ever pay off, and which is harder to change or revert than the opposite decision.

Duplication of code reduces the effort only for a short term, but it will increase the maintainance efforts almost immediately, proportional to the number of duplicated lines of code. Note also that once code is duplicated, it will become hard to remove the duplication when it turns out this was the wrong decision, whilst if one does not duplicate code now, it is still easy to introduce duplication later if it turns out sticking to DRY was the wrong decision.

Said that, in larger organizations, it is sometimes beneficial to favor independency of different teams over the DRY principle. If removing the duplication by extracting the 95% common parts of the APIs two a new component leads to a coupling of two otherwise independent teams, this might not be the wisest decision. On the other hand, if you have limited resources and there will be only one team maintaining both APIs, I am sure it will be in their own interest not to create any double effort and avoid any unnecessary code duplication.

Note further it makes a difference if "Home" and "Agency" APIs are used by fully different applications exclusively, or if one might try to write a component build on top of those APIs which can be used in a "Home" context as well as in an "Agency" context. For this situation, having the common parts of the APIs exactly identical (which you can only guarantee if the common parts are not duplicated), will make the development of such a component probably much easier.

So if it turns out there will be really different sub teams, each one responsible for each of the APIs, each one with a different schedule and resources, then it is time to duplicate the code, but not "just in case".

If people start reasoning about design with the words "if tomorrow", this is often a big warning sign for me, at least if the decision includes extra work and effort for which noone really knows if this will ever pay off.

Said that, in larger organizations, it is sometimes beneficial to favor independency of different teams over the DRY principle. If removing the duplication by extracting the 95% common parts of the APIs two a new component leads to a coupling of two otherwise independent teams, this might not be the wisest decision. On the other hand, if you have limited resources and there will be only one team maintaining both APIs, I am sure it will be in their own interest not to create any double effort and avoid any unnecessary code duplication.

Note further it makes a difference if "Home" and "Agency" APIs are used by fully different applications exclusively, or if one might try to write a component build on top of those APIs which can be used in a "Home" context as well as in an "Agency" context. For this situation, having the common parts of the APIs exactly identical (which you can only guarantee if the common parts are not duplicated), will make the development of such a component probably much easier.

If people start reasoning about design with the words "if tomorrow", this is often a big warning sign for me, at least if the decision includes extra work and effort for which noone really knows if this will ever pay off.

Duplication of code reduces the effort only for a short term, but it will increase the maintainance efforts almost immediately, proportional to the number of duplicated lines of code. Note also that once code is duplicated, it will become hard to remove the duplication when it turns out this was the wrong decision, whilst it is still easy to introduce duplication later if it turns out sticking to DRY was the wrong decision.

Said that, in larger organizations, it is sometimes beneficial to favor independency of different teams over the DRY principle. If removing the duplication by extracting the 95% common parts of the APIs two a new component leads to a coupling of two otherwise independent teams, this might not be the wisest decision. On the other hand, if you have limited resources and there will be only one team maintaining both APIs, I am sure it will be in their own interest not to create any double effort and avoid any unnecessary code duplication.

Note further it makes a difference if "Home" and "Agency" APIs are used by fully different applications exclusively, or if one might try to write a component build on top of those APIs which can be used in a "Home" context as well as in an "Agency" context. For this situation, having the common parts of the APIs exactly identical (which you can only guarantee if the common parts are not duplicated), will make the development of such a component probably much easier.

If people start reasoning about design with the words "if tomorrow", this is often a big warning sign for me, at least if the decision includes extra work and effort for which noone really knows if this will ever pay off.

Said that, in larger organizations, it is sometimes beneficial to favor independency of different teams over the DRY principle. If removing the duplication by extracting the 95% common parts of the APIs two a new component leads to a coupling of two otherwise independent teams, this might not be the wisest decision. On the other hand, if you have limited resources and there will be only one team maintaining both APIs, I am sure it will be in their own interest not to create any double effort and avoid any unnecessary code duplication.

If people start reasoning about design with the words "if tomorrow", this is often a big warning sign for me, at least if the decision includes extra work and effort for which noone really knows if this will ever pay off.

Said that, in larger organizations, it is sometimes beneficial to favor independency of different teams over the DRY principle. If removing the duplication by extracting the 95% common parts of the APIs two a new component leads to a coupling of two otherwise independent teams, this might not be the wisest decision. On the other hand, if you have limited resources and there will be only one team maintaining both APIs, I am sure it will be in their own interest not to create any double effort and avoid any unnecessary code duplication.

Note further it makes a difference if "Home" and "Agency" APIs are used by fully different applications exclusively, or if one might try to write a component build on top of those APIs which can be used in a "Home" context as well as in an "Agency" context. For this situation, having the common parts of the APIs exactly identical (which you can only guarantee if the common parts are not duplicated), will make the development of such a component probably much easier.