1

I have an application 'A' that was over engineered using Amazon SWF to do jobs asynchronously. We are re-writing it to app 'B' to keep it simple and do the same jobs synchronously without using SWF. The actual code that does the job was kept clean and separate. Application 'A' will eventually be decommissioned - say like an year or two from now.

I am considering to avoid code duplication while we develop 'B'. I could think of

Creating a common library

Pros:

  • Any new code added for app 'A' will come into 'B' as well.
  • Code is not duplicated.

Cons:

  • Since app 'A' is stable, modifying its code to separate to a library can be complex, takes effort (which may not give enough returns) and also bugs may be introduced.
  • No other app uses the library after 'A' is decommissioned at which time it does not make sense to have a library.

Live with code duplication

Pros:

  • New app can be designed as required with no frills.
  • No unnecessary library management.
  • App 'A' will be stable.
  • Lesser effort.

Cons:

  • Code duplication

What is the best way to go about this?

2

1 Answer 1

3

This ultimately depends on how complex your application logic is and what your commitment level and time period for decommissioning "A" is.

Let's first discuss the latter. If there is a possibility that the decommissioning of "A" will be delayed/postponed for many years or if your organization or your successors will lack the willpower/motivation to do so then you should not duplicate the code. You should instead focus on refactoring "A" to address specific problems (unless of course the code is hopelessly bad and deserves to die in which case you should make sure that "A" ultimately does get decommissioned).

Now a word about complexity. Decommissioning "A" can be a tall order and you may want to chalk out a concrete strategy for doing that before embarking on building "B". If you don't then during the decommission you risk encountering a use-case/feature which only "A" can support and "B" cannot [easily] because of design decisions you took for "B". This is particularly important if you design "B" with no frills (which in my experience always risks missing subtle behaviour).

I will also like to warn about creating a shared library. If ultimately you do end up maintaining both "A" and "B" you may encounter a lot of problem with the library approach.

Shared libraries can pose a massive versioning problem. For a simple example, consider the case where "A" is running on Java 6 while "B" is being developed with Java 8. The shared library will be forced to be in Java 6 (end of life in the premium support model). Will you carry over this risk? Even if you are happy to live with that, what if there is some behaviour in this library that works differently based on the run time (Java 6 vs Java 8)? Where will you issue the fix? Similar problems will exist in non-Java applications as well.

I am not saying that you should copy/paste code to avoid this complexity but just be aware of it so that you can plan for it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.