tl;dr

The purpose of this post is to highlight the problems with the development workflow between frontend & backend developers working with the Sitecore CMS platform. Future posts will highlight some potential solutions available already and my own personal experience at resolving “The Process Inefficiency” with frontend, backend & Sitecore solutions.

The Process Inefficiency

The process inefficiency is a blog series, looking into common development processes working on Sitecore projects. The series takes a deep dive into known problems, the questions we should be asking and looking into potential solutions. This is the first in the series and will be heavily dictated by community input and feedback as there is never a one solution fits all approach to many of these processes. The key is finding the one that best fits the team working on the project.

The Problem

Essentially when working with any .NET web application there is crossover when working with HTML/CSS, JavaScript and .NET MVC Razor views or .NET WebForms. This crossover means backend developers touch the work of frontend teams to integrate the markup or frontend teams try to use backend written HTML Helpers or inline server code written by backend developers to complete their markup.


backend vs frontend faceoff

The problems we have derived

  1. Markup lives in the domain of the backend and frontend solution.
  2. Developers need to understand markup, stylesheets & javascript.
  3. Frontend developers need to understand inline server code or provided html helpers to complete dynamic markup generated based on dynamic data sets.
  4. A problem not derived from above but known in the Sitecore world is supporting different markup, stylesheets & javascript for the experience editor.

Why do these problems become a real issue to the development processes in place?

Developers from both ends of the spectrum break work done by others in the project team. This causes problems that are usually only identified on integration servers or QA stack where QA Testers get to have a field day. Avoiding this should be our goal, over all reducing time spent to bug fixing on real bugs and improving build quality of the solution. Ultimately bringing costs down everyones dream.

Sidenote: There are a select few from my own experience who have the gift to work both ends of the spectrum without a hitch. However for the most part I can confidently say it is better to seperate and protect work done by each.

Questions to ask

After understanding the problems, teams need to ask the right questions on coming up with a solution to this process inefficiency.

  • What is going on when frontend and backend developers have this crossover?
  • Who owns the markup? How can we give complete control of markup to frontend where it belongs? Is this where it belongs? I believe so. Why? I will dive into the why in my next blog post after input from the community.
  • What do we need to do to support Sitecore experience editor and not degrade the expected experience for a content editor?
  • This is where I get the community to pitch in. What other questions can we ask to help understand the problem better to provide a potential solution?
  • How can this fit into the helix pattern framework being pushed as a Sitecore standard?

I will leave this here for a time, and write a community summary of findings.

Community Summary


backend & frontend harmony

The article series breaks down the out of the box process and highlights areas that can be improved. It’s opening up the debate on the issues and asks you to join in with the debate. Join in on Sitecore slack community, in Sitecore-chat channel when talking and mention @anicho to get my attention. Use comments below or tweet me. Reference #theprocessinefficiency #sitecore on twitter.