What I want to talk about today is a special case of code duplication: when we take an F&O application element created by some other company (Microsoft, ISVs or so) and create a copy in our model.

Usually, people do it to deal with code that can’t be accessed or extended, e.g. when we want to use code of an internal class. Duplicating the element and adjusting its code can be done in seconds; it’s much easier than carefully thinking about other solutions, creating extensibility requests and so on.

But it’s expensive in a long term. Everything is fine as long as the original element remains the same, but what if Microsoft fixes a bug, ISVs adds a new feature by extending the standard element or so? You have two options:

1. Identify changes and apply them to your copy

When you receive a new version (of the standard F&O application, of an ISV solution), you’ll find changes of all elements that you’ve duplicated (and their extensions) and you’ll implement them in your copies too.

Both the identification and the implementation requires time and effort and as with any other development, there is a risk of making a mistake. A big problem is also a lack of tools helping with this scenario.

2. Ignore the situation

Unfortunately, this is the usual approach. You keep using the old logic and hope that it won’t cause any problems. Note that this doesn’t just mean that you’re missing a particular feature. The behavior may be unpredictable, because you may be mixing the old and the new logic. For example, Microsoft two changes methods to fix a bug. One change gets applied, but the other one doesn’t, because you’re using a copy with the old code. What will happen is impossible to say; it may end up with corrupted production data or anything. The problems gets bigger and bigger over time.

Both approaches are expensive. It takes time to proactively maintain all copies every time when you get a new version of models from Microsoft or ISVs. What is the cost of ignoring the problem is hard to predict: it may be fine, it may cause you some troubles while dealing with missing features or olds bugs (already fixed in standard code), it may ruin your application update schedule (because you find too late that your code doesn’t work correctly on the new version) or it may cause something catastrophic. It’s not guaranteed to fail, but it’s a lot of risk.

When you consider duplicating an application element owned by another company, you should think about the cost of maintaining the copy. You should try to avoid the duplication, because then you don’t have to deal with these problems. If you have to, you should have a maintenance process used every time when you apply a new version.

If the reason for duplication is that the object can’t be extended or reused in the way you need, create an extensibility request to get the actual problem fixed. If you can’t wait for the fix (it takes a lot of time indeed), duplicate the element but consider it a temporary solution. Add a reminder to re-implement it when it becomes possible.

And if you have to duplicate something, make sure you do it right. For example, a common mistake is duplicating a data entity and keeping the same label, despite of getting compiler warnings about it. Only one of them will have a label in the list of entities in GUI.