Last week I had the pleasure of attending a workshop on Helix, presented by Derek Correia. The mindset I had going into this was “I’ve seen the presentations, I’ve been working with Helix a bit, this will be nothing new.” I was pleasantly surprised to be wrong.

If you’re not already aware, Helix is Sitecore’s recommended set of design principles. You can see a live example of Helix by checking out the Habitat demo. Helix is impressively well documented and I recommend checking it out.

Rather than talk about what Helix is, I want to focus on a list Derek presented of what Helix is NOT.

Helix is NOT System Architecture Helix is NOT Software Design Patterns Helix is NOT about reusability

Helix is NOT System Architecture

There are a whole lot of great tools out there to suit many project needs, but Helix doesn’t force you to use any of them. Sure, the Habitat demo has integrations with Unicorn for item serialization. There’s probably some form of CI that’s building it. Do you have to use any of these? No. Hedgehog has made some changes to TDS to allow it to integrate with Helix more easily. Want to use Jenkins for CI? What about TeamCity? You pick. I recommend TeamCity, but what do I know about what’s best for you? There are tons of tools out there for many different tasks – go with what you’re comfortable working with.

Helix is NOT Software Design Patterns

Derek talked a lot about this. Helix doesn’t force you to write code one way or another. There are a few recommendations, however. I’d recommend you check out “Clean Code” by Robert C. Martin. The only thing Helix asks is that you respect boundaries. Features shouldn’t reference other features or Projects. Foundations shouldn’t reference Features or Projects. That’s the key. How you write the code within these modules is up to you.

Helix is NOT About Reusability

This one was the most interesting one to me, and it raised a few eyebrows at the workshop. I was under the impression that the modularity of Helix was to promote DRY code that can be taken from one solution to the next. If I make a “Search Module,” the goal of that module was to be fully self-contained so that it can be reuseTaking on Needless Dependenciesd elsewhere. That is not the case. Helix is about untangling dependencies and making solutions readable.

A side-effect about containing things within a single module is that it could encourage you to write the same code more than once. The simple solution is to refactor reusable code into a Foundation module, however the Helix architecture doesn’t state that you need to. For the Helix architecture, it’s perfectly acceptable to write the same code in two difference places to reduce the dependencies. To be clear, that’s not something I’d recommend. I’d encourage identifying similar functionality and creating a Foundation module for that instead.

Final Thoughts

I found the workshop more interesting than I thought I was going to. I applaud Sitecore for setting this up and look forward to more of them in the future. Derek did a great job with the presentation and kept everybody pretty engaged.