Skip to main content


Sitecore Symposium 2019: Managing Technical Debt While Implementing Helix Principles


This session provided a basic look at technical debt – what it is and where it comes from.  It also offered some suggestions on working with legacy code and Helix together. Here are my key takeaways:

  • What is technical debt?
    • A measure of how untidy your code is
    • Any time when you look at your code and wish it was better
    • A barrier to code reuse
  • Where does it come from?
    • Implement fast and easy solutions to meet a deadline
    • Junior developers – they do not know better
    • Senior developers – they are stuck in their own ways or stop learning
    • Passage of time since code was written
    • Updates to best practices
      • What is best practice today may not be best practice in the future
  •  Helix:
    • A set of patterns for Sitecore development
    • Mostly defined for C# backend code opposed to frontend code
    • Helps developers know where to put their code
  • Target architecture – Dependencies go top to bottom
    • Project
    • Feature
    • Foundation

target architecture

  • Moving from legacy code to Helix
    • Not easy if the code did not follow good practices when it was written
    • Large scale refactoring is a bad idea
      • Better to move one piece at a time
      • Move dependencies, create interfaces, setup dependency injection
    • Large sections of code may never get refactored
      • “If it ain’t broke, don’t fix it”
      • Very hard to regression test an entire application
    • Leave code better than you found it
      • When working in legacy code, clean up the area of the code you are working in if possible
      • You need to test the section that got updated anyhow

Development process:

  • Create a component library
    • A basic HTML/CSS site that shows off the UI components
    • Testable by QA early in the process
    • Easier to make changes before renderings are built
  • Code Analysis
    • Automatic code quality checking
    • Helps you find simple errors
    • Can check for coding standards
    • Can be a waste of time on legacy code if you don’t plan on fixing the errors
  • Code Reviews
    • Difficult if you have never done them
      • Can lead to awkward conversations or hurt feelings
    • Goals
      • Improve code quality
      • Become a better team
      • Have more than one set of eyes on the code
    • Priorities
      • Understanding – Most important
      • Correctness
      • Design
      • Improvements
      • Coding style – Least important
    • Build Automation
      • Build every feature branch
      • Build and deploy the develop branch
      • Let QA control deployments to QA environments
      • All deployments should be push button

That’s a wrap on another session. Be sure to follow all my session reviews and tweet me if you have any questions or want me to write about a particular topic!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Eric Sanner, Solutions Architect

More from this Author

Follow Us