13 reasons why you should avoid reusing your old code during Sitecore development

By: Solution Architect Grant Bartlett

Saving time and money are easy draws considering a new website, and one of the easiest way to do both is to reuse an existing code base. Here are 13 reasons to avoid it in your next Sitecore build:

Planning a new Sitecore website is an enormous undertaking; from user stories and planning to development and design, it’s common to have stakeholders asking for recommendations on elements that can be brought over from a previous website as a way of saving time and/or money. Being asked to reuse code base that was written for an original website is one that we have run into often. It’s an understandable request, as code reuse has certain potential advantages:

• Less code to write means less time to production which results in money saved
• The business logic is already written, so it doesn’t need to be reproduced
• Due to aggressive timelines reusing existing code can act as an interim step and upgraded later

On the surface, those are all excellent observations, but don’t necessarily illustrate the full picture.

I’ve put together a list of 13 things to consider when talking code reuse:

1. Potential for new HTML

If the code being reused has HTML, it will likely not be compatible with the new site’s HTML. The picture becomes even more muddy if JavaScript/JQuery functionality is part of the picture. Clashes between existing JavaScript/Jquery and the new build is typical and expected.

2. Reusing a sublayout or web control

If the code being reused is a Sitecore sublayout/webcontrol, remember that this control will be included in a layout that will be part of a completely different code base and will likely lose some if not all of the original functionality.

3. Field placement

If your controls are dependent on fields in Sitecore or their relative placement in the organization of your Sitecore content tree, it is likely one or both of these things will change.

4. Global configuration settings

The global configuration settings of the new build will likely be different from your existing build. For example, web.config entries will likely change and these settings are global and impact code execution.

5. .NET framework considerations

Upgrading your site may also mean jumping a version of the .NET framework, potentially impacting your code execution.

6. Upgrading your Sitecore instance

Rarely is a new build rolled out without upgrading your Sitecore version which itself can introduce unforeseen issues. Starting to consider an upgrade to Sitecore 7.5? Whether you’re ready to startusing the xDB or hoping to be well-prepared for Sitecore 8, there are a few things to consider.

7. Code functionality

Do you know what your current code actually does? Must fix bugs get reported due to the rigorous QA of a new build. Oftentimes, these issues were present on the previous site, but went unnoticed.

8. Technical improvements

With new technology comes new functionality that your existing controls may not support. Take the Sitecore Digital Marketing System for example- it’s functionality is constantly being changed and improved and it’s entirely likely that your old code won’t be able to support it accordingly.

9. Changes in agreed upon best practices

As technology evolves, so do best practices. Your code may have been built with best practices in mind at the time, but now those are likely out-dated. Wondering what a few of those best practices may be? Our 12 laws of Sitecore development, written almost a year ago, is still one of our top read blog posts on the site.

10. Code complexity

Be aware of underestimating the complexity of your existing code base. Can your code be easily extracted from your existing code base? Are there dependencies that need to be accounted for and pre-work that needs to be done to extract the code.

11. Architecture decisions

Do you need to make architecture decisions in your new build to accommodate your existing controls?

12. In-house development skills

Oftentimes, the original developers behind the code have moved on. Should there be a need to dig into the code base, do you have the expertise to facilitate it?

13. New performance metrics

Does your existing code meet the performance metrics of your new site?