It’s been a few years since the Sitecore Habitat codebase was open-sourced and promoted as an example of best-of-breed Sitecore development. That was soon followed by Helix, a set of principles that developers can use to produce their own high quality Sitecore solutions.
Helix and Habitat marked a turning point in the way in which Sitecore interacts with its community of developers. Until then, the best guidance was a generic. A ‘Recommended Practices’ document and a handful of experts sharing their knowledge on Stack Overflow.
The result was that each development house adopted their own standards and practices – some good, some not so good. That’s why Sitecore took the positive step of specifying an official standard against which all Sitecore solutions could be measured.
Working for Kagool, I see a lot of Sitecore codebases written by companies from around the world. There’s no doubt that Helix and Sitecore Habitat have dramatically improved the quality Sitecore solutions. But I’ve also seen many solutions that claim to be ‘Helix compliant’, and even look like the real thing. Look a little closer and you’ll see that they demonstrate none of the values and benefits of the underlying Helix philosophy.
So why has this trend formed? Helix has plenty of documentation; an official website, YouTube workshops, numerous ‘How-To’ blog posts from the community. Yet time after time I see Sitecore websites that have been built to look like Habitat, but somehow completely miss the point.
Sitecore Habitat is to blame, in my opinion.
The Trouble with Sitecore Habitat
Let me clarify my position. I think Sitecore Habitat is a solid demonstration of the Helix principles, and a vital learning aid for developers getting started. I have quite a few Helix sites under my belt and I still reference Habitat from time to time.
Habitat is just one interpretation of how to implement the Helix principles. It isn’t the only way to do it. This is not a new observation. The Helix documentation begins with an entire section highlighting the distinction between the two. Even so, Habitat makes it too easy for lazy developers to cheat. While Helix takes a lot of time and mental effort to master, it’s much easier just to reproduce the look and feel of Habitat without putting in the real work.
When developers focus all their attention on Habitat, they fixate on the details of the implementation and lose sight of the real reasons for doing it. They don’t get any of the benefits that Helix is meant to deliver. What’s worse is that it also tends to lead to resentment – ‘I have to do all this extra work just to satisfy the Helix police!’.
On countless occasions, I’ve been told ‘Helix slows me down’. That point of view surprises me. When done correctly, Helix should streamline the development process. Refactoring should become simple. Team members should be able to easily work on multiple features in parallel. Maintenance should be predictable and stress free.
In my experience, what those less driven developers really mean is that copying Habitat parrot-fashion slows them down. Well of course it does! If you choose the easy road and create a codebase that mimics Habitat without knowing why you’re doing it, then how can you leverage any of the benefits
Every architectural decision you make when developing your Helix solution should be firmly rooted in its principles. It should be an attempt to maximize agility, extensibility and maintainability. By simply duplicating Habitat you aren’t really making any decisions at all.
Sitecore Habitat, forget it and think for yourself
You can develop a perfectly valid Helix solution that looks nothing like Habitat. So long as you make well-informed decisions that respect the principles, you can tailor it to suit your team’s preferences.
For example, UNRVLD's frontend developers dislike the Habitat approach of storing Javascript and CSS files in various different Visual Studio projects. Instead, they find it more convenient to replicate the Helix layers and modules in the file structure of a single project.
The important point is that they’ve assessed the Habitat approach, how it adheres to the Helix principles, and the benefits it offers. Then they’ve come up with their own approach based on a sound understanding of the pros and cons. The real value of Helix emerges when an expert team weighs up the various options and comes to a consensus for the best approach.
Sitecore Habitat is a valuable resource, but when I review a Helix codebase I want to see evidence that the developers have spent time carefully considering their approach. I want to see that they’ve aspired to the core principles, even if they haven’t complied with the Helix conventions to letter.
If the alternative is a superficial Habitat clone with no thought invested whatsoever, then in my opinion it’s wasted effort . There are no shortcuts to quality.
.webp)
.webp)