Inside Look at a Real World Web Project – Planning, Strategy, Design, and Implementation

by Max Slabyak

My team and I just deployed a high-profile, albeit small website for one of our brands. This article will give you an inside look at each step of this real world project, which you may not necessarily be able to find in a WROX publishing book. I will cover the project framework, overall design strategy, and working with Sitecore. In a cross-post, one of my teammates, @kaidez [], go into the detail of front-end code and some of the invaluable tools that simplified the general development of this project.

Project Framework

For our framework, we chose SCRUM. In a 4-person web team, all sitting within reach of each other, we have found that over the years, this works best for us. The designers know what the developers are doing and vice versa. Like SCRUM, we are fast and efficient. In fact, I am very proud of my team. As a 4-person standalone web design shop, I think we’d do rather well, assuming we wouldn’t have to pay for our own healthcare.

In the role of ScrumMaster, the first thing I did was set up a storyboard in (pronounced scruh-mee, not screw-me, which is a completely different NSFW site). If you haven’t used this tool before, give it a try. Its drag-and-drop interface lets you create stories, associate tasks with a user, and drag-and-drop them from column to column (to-do, in progress, verify, complete). Maintaining a storyboard like this, not only puts your project manager at ease, who may be in a remote location, but also keeps the team sane when you need to get out of the coding zone and get a perspective on the project progress.

Design Strategy

If you only get one takeaway from this, it’s that no matter how small the project, proper design and planning will always serve a benefit.

Since we adopted Sitecore as the official CMS tool, our design was already partially established. With this being a small product informational site, our Sitecore template design was not unlike the Sitecore demo project. The difference between our solution and the demo project is the level of OOP design.

What I have seen with novice Sitecore developers is as soon as they start developing a site, they completely abandon n-tier architecture and OOP best practices. Sitecore does not and should not replace a good OOP design.

Take the Product entity as an example. A Product may have a name, image, link, and a description. In a 3-tier (DAL/BLL/UI) architecture, you would create a class for it in the Business Logic Layer. In our case, we display products in a category page and in a product page. If you care about your code, there should be an alarm that goes off that detects duplicate functionality and tells you to extract it to one common place; hence, the need for our BLL assembly.

If you are still not seeing the benefit, consider the readability and general elegance of binding an asp:repeater to a List of products with dot notation and intellisense, as opposed the ugly DataBinder.Eval() function.

<asp:Repeater ID="rptProducts" runat="server">
		<a href="<%#((Product)Container.DataItem).Link)" %>
			<%#((Product)Container.DataItem).Image) %><br/>
			<%#((Product)Container.DataItem).Name) %>

As another best practice, you will want a Core assembly to keep track of static constants and variables. In our case, it holds the URL to our CDN which is different from environment to environment.

Team Development Environment

After the design is knocked out, I have to make sure everyone’s development environment is properly set up and wired up to TFS. I’ve seen developers skip this step until the project is complete, but I cannot stress this enough – these shortcuts will only make your life more difficult. Set up TFS before you start development and don’t forget to check in changes to avoid having other developers overwrite your changes or hearing the never-old “well… it works on my machine” phrase.

The Sitecore templates were done during the design phase in a true Agile environment – in a locked conference room with the entire team, so at this point, it was safe for everyone’s environment to be pointed at the same Sitecore database environment since the templates weren’t really changing.  I created the solution with by including the Sitecore files and assemblies, created BLL/Core projects, and checked everything into TFS, after which everyone did a GLV (get latest version).

Sitecore Deployment

We build this site using Sitecore v6.4. With this version, there is no staging module that you have install like with v6.1, so I thought that after I take care of the checklist in Sitecore’s Configuring Production Environments handbook, I’d be home free, but not so. If you want the cache to automagically clear after publish, you will have to set the EnableEventQueues property to “true” in your web.config


A little planning and preparation before will save you a lot of fan cleaning later. No matter how small the project, if you are in a real world environment, chances are it will at some point grow or will probably need maintenance. Following best practices in the beginning, you will avoid cursing yourself and/or your team when it’s time to do that maintenance or expansion.

  • Remember to use a project framework that will fit your team and organization, whether it’s SCRUM or something else. If it’s something else, you will still find to be useful for simple task management.
  • Use TFS, or something else if you don’t have TFS, for source control early on before development kicks off.
  • Do not disregard a good n-tier design just because you are working in a CMS.

Check out @kaidez’s cross-blog on this topic here:


Leave a Reply

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