Building a Sitecore website is quite easy–sometimes maybe even too easy.

When new Sitecore developers follow the Sitecore three-day developer training module, they will get quite far in building their first Sitecore solution from scratch—speed of development applies even more for experienced developers and teams. In my experience as a developer and technical architect, my team and I have astounded many product owners and customers by banging out a large piece of the solution’s functionality in a very short period of time.

But as a developer and technical architect, you should realise that you hold enormous power in your hands when you are taking those first steps. One could even claim that you have the power to make or break the business case for the project in the long run. 

The Sitecore® Experience Platform™ holds enormous potential for marketing but no customer deploys the whole platform to its full extent in the first shot. Therefore, there are grounds for a long-term implementation process, provided that the solution is architected and built with extensibility and flexibility in mind. On the flip side, if the initial solution and architecture is not up to the challenge, it has the power to stop progress in its track and stifle marketing from harnessing the power of the platform.

Flexibility, Extensibility, and Simplicity

So whether you are a developer or technical architect, when putting together your site architecture and your solution, one of your primary concerns should be maintainability and flexibility in the long run. Over time, being continuously vigilant about the process will make you a lot more productive than if you continue to take the most obvious and quickest way from A to B.

And long-term productivity is the reason why we need conventions, practises, and architectural principles.

But which principles, practises, and conventions to adopt largely depends on the business case as well as your internal organisation since many factors, for example skills and maturity, play a vital part in this process. So defining conventions or finding the right principles and practises doesn’t happen in an instance and one of the tricks is to be constantly vigilant about what you are doing, how you are doing it—and most importantly, why you are doing it.

But keep in mind that however boring and annoying they might sound: conventions, patterns, and practises are in place to optimise the return of investment for the business.

Ask yourself: Why?

All through the development process, as you are pondering technical decisions and even for each line of code you are writing, you should continuously question yourself, the architecture, and the process. For example, you could ask yourself these questions as you go along:

“Does this belong here?”

Why are you placing this line of code in this method, this method in this class, this template in that folder, etc.? Is there an underlying convention that you are not following or are you making a temporary decision because the right way might take too long?

Clean architectures and conventions often start crumbling because of rash and quick decisions or small imperfections. After all, if your team members take the easy route, why can’t you?

Another reason for correct architecture to go sour, is because doing it the right way is too hard or slow—and for what seems to be immediate productivity reasons, we start doing things the wrong way. As a consequence, your question should be: is there a process we can change or a tool we can introduce to speed up things and make it easier? After all, just because conventions and practises are made to optimise business doesn’t mean that they shouldn’t be easy or fun to follow, right?

 “Why are we doing this?”

Conventions needs to be understood to be followed.

Take for example ASP.NET MVC. These conventions are easy to understand and follow as they are built on simple naming principles and have tools which optimise development if you follow them.

But sometimes we catch ourselves following conventions for no apparent reason. Maybe it’s because they were taught to us by an authority, in training, etc.? Or maybe we are too consumed with getting on with the tasks at hand to halt and ask ourselves why these conventions are in place.

For example, many of the commonly seen practises of Sitecore, such as:

  • Using the Common/Folder template for everything remotely resembling a folder.
  • Deriving all your templates from a common base template.
  • Placing webforms renderings in the layouts folder on disk.
  • Working outside (or inside) the website root.

…can and should be reconsidered in the context of your solution and the organisation you are working in. What ramifications do these practises have for you and the business and is there a better way?

In other words: If you cannot answer “why,” ask your team and if you still have no answer, then consider change.

“Can we do better?”

Unquestionably, the best and most effective way to make sure that you and your team members build solutions the right way, is to all agree that it is indeed the right way.

If there is no apparent reason a process or architectural decision is in place—or you are absolutely sure you know the reason and you disagree and think you can make it better, then it is your obligation to put forward why it should change and how to make it better.

But always keep in mind:

  1. Do not argue from a technology or personal perspective but always from a business perspective. Will this make the solution better in the long? Will this change save time or resources?
  2. Listen and prepare to lose the argument. Although you are a smart developer or architect and you know what you are doing, you might not know all the business reasoning behind a decision.
  3. And most importantly: don’t start doing things your own way. One uniform set of practises will always outperform a diffuse and growing set of practises in the long run.

Adopt and adapt makes for best practises

In summary, in the bigger picture it is not important which precise conventions and practises you chose to follow. The important thing is that you think through why you have those conventions—and that everybody knows and understands why—and that it is easy to follow them.

Any practise you chose to adopt can only be a recommended practise to start—it is only when you align them to your business requirements and take them on as your own that they truly become a best practise.

For further reading and examples of conventions and practises, check out the Habitat project site or our work on github.