“Estimate” – redefine or new term?

About once a year I have a big discussion with one of my colleagues about the concept of estimation. From a professional point of view, we come from different backgrounds. I am a developer and technical architect, and he comes from a background in project management and communication. This year we came to a conclusion that our disagreement is not in what the craft of estimation is or what an actual estimate is – but rather how to approach the common perception (or misperception) of an estimate.

Most people think of an estimate as the number of hours required to solve a given task. If we assume that this is the actual definition, we would have to assume that the task is well defined and completely fixed and this is always – yes, always – not the case. The Cone of Uncertainty (http://en.wikipedia.org/wiki/Cone_of_Uncertainty) states that an estimate is never precise (the uncertainty zero) until the task is complete – in other words: both the task at hand (scope, requirements, possibilities etc.) and the number of hours (or sum of money) required to solve it is nothing more than qualified guesswork. We all know this, right?

A fact of the matter is that quite a lot of our clients are not agile. In essence, they do not accept risk in an IT project, and trust us to carry that risk. This means that clients need to know the price of a given requirement before commencing on the work, which means that we have to estimate the “number of hours” required to solve “a given task” – and that the number of hours will not be flexible. Which bring me down to the greatest misconception of the above definition – that the “given task” is also not flexible.

For a great many years I have been one of the lucky developers attached to technical presales – and thereby responsible for estimation in the sales process. Now, if I had a penny for every receiving developer who has moaned about the “number of hours” on my estimate I would be a very rich man. In other words, it seems that many developers think that the “given task” is as fixed as the number of hours – why else would they moan about the hours instead of spending time on resolving how the solve the task within the timeframe? In these developers heads, there is only one solution to the task – and the problem is therefore the number of hours given to this solution. In my experience, there is never just one solution to a given task.

Coming back to my discussions with my colleague: What we agree, is that we need to emphasize – both to our developers and to our clients – is that in a fixed price project, the flexibility lies in the tasks, not in the number of hours. The disagreement is how we emphasize this to our clients and developers.

Call me an idealist or a dreamer, but I still think that key lies in communicating a broader definition of an “estimate”; something that makes it obvious that there is so much more to an estimate than a one-liner task description and a number.

I suggest the following definition of an estimate:

The assumed volume of a task with the knowledge of scope and value at a given time at with a given experience.

This definition emphasizes knowledge of scope and value, as well as context such as the time of estimation and the experience of the estimator. I know it’s not an easy definition, but I think the emphasis is important.

I know that I should probably back down and realize that the common misperception of an estimate is going to be dominating – but that would mean that I would have to let my colleague win the discussion. And I am just not ready for that…


Sitecore Symposium 2012 – Hopes and Expectations

Tomorrow is the Sitecore Symposium 2012 in Amsterdam. I am going and here are some of my hopes and expectations as a Sitecore technician and architect:

Wednesday 9:15, Keynote

First of all, Sitecore has been waving version 7 in our faces for a while. The last year’s conferences were full of promising new features – will this be the time when we hear something concrete?  I therefore hope (although not exactly expect) to hear a keynote with a working demo of Sitecore 7. Michael Seifert is growing into a fantastic speaker, so if he has the product, he will be able to deliver the wow factor.

Wednesday, 15:30: Developer Track, Multiple Ways to Multisite Solutions

One of the eye-catching sessions for me has got to be the multi-site session by Tim Ward. Over the years, we have pretty much delivered multi-site solutions to ALL our clients. I’ll be interesting to get the official Sitecore take on the problem. Furthermore I am very comforted by the fact that Sitecore actually has a take on it – given the problems we have faced historically with lack of multi-site support in some of the official modules.

Wednesday, 14:15: Sponsor Track, Preventing the Language Chaos
Thursday, 11:15: Sponsor Track, Sitecore Translation Strategies and Techniques: Which One Is Right for You?

During the conference, there are talks by two translation/localization vendors: Clay Tablet and Lionbridge. In the last years translation support is one of the key features our enterprise clients request, and it’ll be interesting to see if the vendors gives us some nice technical integration tips. Although I must say, I do expect sales pitches from both sessions.

Wednesday, 15:30: Sponsor Track, Best Practice for Performance Tests Within CMS Installations

The Sitecore Partner Apica has a session about performance testing and best practises. Seeing that this is a techie talk on the sponsor track (which in itself is a contradiction in terms) I’m hoping for a surprise wow experience.

Wednesday, 16:30, Product Track: Building, Connecting and Measuring Communities with Sitecore

Social media and social web features are seemingly always very important to our clients – and why?  “Well because everybody else has it”. In this light, I’m expecting John Field to give me some Sitecore recommendations on how to prove the value – or lack of same – to the clients. Secondly, Sitecore recently purchased a large share of the Danish Facebook integration company KOMFO – I’m hoping for the conference to shed some light on what this collaboration could mean.

Wednesday, 16:30, Sponsor Track: Sitecore and Salesforce – A Compelling Case for Unified Customer Engagement

During the last year, a number of our clients have shown a very keen interest in the CRM integration part of DMS – turning their website into a direct sales tool, integrated with their sales department’s weapon of choice. A nicely done Salesforce/Sitecore integration could give us an additional tool in our integration toolbox.

Thursday, 9:00, Developer Track: Breaking a Million with a Bucket of Items

Buckets are in my world, the next HUGE thing in Sitecore – and something which have been waved around our nose in years. I hope to see massive amounts of data, easily indexed and faceted AND extracted with a nice and neat API. And how does the bucket data tie in with the hierarchy that we know today? Furthermore I hope – well I might even venture an “expect” – to see the concrete implementation and a glimpse of Sitecore 7.

Thursday, 12:15, Product Track: Sitecore Roadmap – Where Are We Going with the Product

This I guess is always a conference must-see. This is where I expect more Azure integration, more social media stuff, more enterprise features, closer integration to ERP and CRM, more app center services from Sitecore etc. etc. Although I hope to see a glimpse of what’s beyond Sitecore 7 and, pretty please, some focus on integration and the development community – and not just new features.

Thursday, 14:00, Developer Track: Become the Marketer’s Best Friend ̶ Using the DMS API to Extremes

The DMS API has never really had any success with the developers within Pentia – and in my view for a good reason: It’s simply not good enough. It just doesn’t have the sleek interface and neatness that the core Sitecore API has. Therefore I’m hoping for an introduction to a clean DMS API in Sitecore 7, although I must admit that I’m expecting an attempt to woo us developers with some features in the current API.

What are your expectations? Hope to see you there!

.NET, LINQ, Sitecore

Inheritance techniques in Sitecore ASP.NET CMS

There are two techniques for inheritance which are commonly used in all Sitecore solutions; hierarchical inheritance and template inheritance. Sadly, Sitecore offers no straight forward out-of-the-box API methods for the two techniques. This post describes some simple and neat ways of implementing these techniques – and also shows of how to use extension methods in .net to extend Sitecore and ASP.NET classes. This post was partly inspired by the extension method contest at the Learn Sitecore website.

Template inheritance:

Template inheritance is an integral part of Sitecore which I hope that all of you Sitecore fans out there use extensively in your solutions. At Pentia, template inheritance is so vital that in practice, you will see no item.TemplateID == SomeID or item.TemplateKey = "sometemplate" in any of our code, just like you (hopefully) would never use MyObject.GetType().Name == "MyClass" in C#.
No, we always use the following extension method:

public static bool IsDerived(this Item item, ID templateId)
  if (item == null || templateId.IsNull || item.Template == null)
    return false;
  TemplateItem templateItem = item.Database.Templates[templateId];
  if (templateItem == null)
    return false;

  Template template = TemplateManager.GetTemplate(item);       
  return template != null && (template.ID == templateItem.ID || template.DescendsFrom(templateItem.ID));

The method is used as item.IsDerived(“MyTemplate”) just as you would always do MyObject is MyClass in c#. Sadly, Sitecore offers no obvious way to do the same out-of-the-box….wait… oh yeah, you could naturally do Sitecore.Xml.Xsl.XslHelper.IsItemOfType()

Hierarchical inheritance:

While template inheritance is used to give all content of different types the same properties, hierarchical inheritance in Sitecore is slightly different. This is primarily used to allow a piece of content, a setting or a configuration to propagate down a branch in the tree – i.e. propogate down a number of content types which can be totally unrelated, but grouped together solely because of their content position. For example, this could be used to apply a given design theme to an entire subsite within you site. Using hierarchical inheritance, extension methods and Linq, this could be accomplished as such (pardon the train-wreck):

protected void Page_Load(object sender, EventArgs e) {
  var theme = this.GetDataSourceItem().GetAncestorOrSelf().First(i => i.IsDerived("HasTheme")).Fields["Theme"].Value;

In this example there are – besides the IsDerived extension method described above – two very useful extension methods:

GetDataSourceItem extends the ASP.NET UserControl to provide easy access to the DataSource set on a sublayout and is implemented as follows:

public static Item GetDataSourceItem(this UserControl control)
  Sublayout sublayout = GetSublayout(control);
  if (sublayout == null)
    return null;
  string dataSourcePath = sublayout.DataSource;
  return !String.IsNullOrEmpty(dataSourcePath) ? Context.Database.GetItem(dataSourcePath) : null;

GetAncestorOfSelf extends item to return a list with the item itself and all its parents – and this is naturally where the key to hierarchical inheritance lies:

public static IEnumerable<Item> GetAncestorOrSelf(this Item item)
  do {
    yield return item;
    item = item.Parent;
  } while (item != null);

I hope this post shows you how some simple extension methods can give you a lot of power in your solutions.

.NET, Architecture, publishing, Sitecore

Drawing the customization line

Sitecore is an extremely flexible system; in fact most of Sitecore is built with the extensibility and customization functionalities which is provided. This includes pipelines, events, commands, SheerUI, providers and more. All in all: there is not much which cannot be achieved in Sitecore and only the imagination of you and your client sets the limits of customizations – and believe me, in my work of helping out clients and Sitecore partners all over the world, I’ve seen Sitecore completely twisted in many ways. I’ve seen Sitecore’s entire layout engine replaced with an item based layout definition, with subitems representing placeholders and subitems representing presentation elements. I’ve seen publishing and item saved pipelines so crammed full of custom functionality that performance was non-existent and I’ve seen XSLT’s with one line of code: a call to an extension function which would return an entire HTML structure as a string.

So where do we draw the line in the holy name of bending functionality and giving the customer “what they want”? Remember:

  • Convincing the client to choose standard functionality is also an option.
  • Each change of standard Sitecore functionality is potentially expensive – for you and for the client.
  • If possible, do not replace Sitecore functionality, extend it.
  • Think about what you put into Sitecore: Content and functionality can be accessed through .NET code and does not necessarily need to be added to the Sitecore DB’s or in a pipeline.
  • Keep track of your customizations – source control it and document it.
  • Remember that your customizations will have to upgrade with Sitecore.
  • Stay true to yourself: If it feels wrong, don’t do it.

In short, just because you can does not mean that you should:-)

Introduction, Sitecore

Getting your Sitecore project right

This post is for you clients who have already selected Sitecore as your new website platform and is starting up a new Sitecore project.
Here are a couple of my thoughts on how you can get your Sitecore project on the right track from the beginning, by setting the stage for a good collaboration with your implementation partner.

The website you a building today should also be the website for tomorrow and hence the website you are building should be extendable, flexible and scalable. It is absolutely possible to build a Sitecore web platform which will last many iterations – considering that you take this into account early in the process.

Select your implementation partner carefully

Your implementation partner is the single most important collaboration partner in your project. They bind everything together; requirement specifications, user experience design, hardware, software, domain knowledge and more, and is therefore crucial for the project’s success. Therefore your primary focus initially in your project should without doubt be to find the right implementation partner.

In my opinion, what you should focus on is:

Human chemistry: A website is not primarily a technological project, but a communication project. Therefore select a partner with whom you can communicate openly and freely. If you sense that they are listening, factors as for example domain knowledge is less important.

Experience: Sitecore is not a difficult tool to learn – but is takes time to master. Therefore, try to find a partner which has multiple large scale projects under its belt, and preferably with projects which has undergone a number of iterations.

Technology based: In my experience, companies which are technology based, i.e. which focuses primarily on the integration and platform parts of the solutions compared to the user experience driven companies, e.g. design agencies, makes more future proof Sitecore solutions. Therefore if you are looking for someone to build your future webplatform as opposed to just your next website, opt for a company with vast knowledge of Microsoft .NET and surrounding technologies.

References: Most implementation partners can most likely show an impressing list of references – but please do not stop there. Call their references and enquire about support, quality etc. Hearing whether their existing customers have gotten value for money is very useful.

Don’t be too specific in your requirement specifications

My suggestion is that you use your implementation partner as a sparring partner on requirements. Remember that these guys have built other solutions before yours and might bring experience, skills and functionality which will benefit you. Also, allowing multiple implementation partners to suggest different solutions to your website’s objective – as opposed to a RFP checklist – will allow you to better evaluate their creativity.

Therefore, in the specifications, try to explain the objectives you have for your company, users or editors, instead of the precise functionality. In Pentia we have had multiple requests for debate forum functionality in solutions – which in our experience is a prime example of a specific functionality which is often never used by users. By explaining which objective the clients wanted to achieve on the website, instead of the specific functionality, we could have advised better, earlier in the process and given more value to the client. By the way; in most cases we managed to dissuade the clients to actually implement the debate forum, and used the precious development time for something much more valuable.

In short: Requirements change. Therefore, being too specific and detailed about functionality already in the RFP process will most likely get you a whole lot of expensive, unused functionality.

Be open about your development budget

This is in my book a no-brainer. The only reasons for not being open about the budget are if you adopt the “they-are-all-thieves-and-robbers” attitude or if you hope to haggle your way to a cheaper website. In both cases, you are doing yourself and your website a whole lot of damage.

First of all, you have to trust your implementation partner, as they hold an immense power to make your project a success or failure. If you don’t, find another partner. Secondly, this is not a standard product you are buying. If you push your implementation partner on time or money, they have but one place to push back: quality. This basically means that your solution will be in a worse state, bringing lower reliability or higher support cost.

Therefore, a selection process is not about getting the lowest price or best solution description. It’s all about finding the implementation partner which you trust the most. And if you found that implementation partner, why not be open about mostly everything, including budget?

Bring your partners on board early

There is a lot of benefit in bringing in all your partners as early in the process as possible – this means both strategy and design partners and well as implementation and hosting partners. Each domain has something to bring to the process and can potentially save you a lot of money and hassle. Getting the implementation partner and hosting partner to talk together as early as possible can save a lot of time in the deployment process, and in my experience, by getting the implementation partner involved in the strategy and graphical design process a lot of hours can be saved in communication afterwards. Furthermore implementation partners often have prebuilt functionality which – if it fits the project – can save you a lot of time and money. The earlier this is brought forward, the easier it is to fit into any graphical design or information architecture.


New releases, publishing, Sitecore, Uncategorized

Dedicated image server in Sitecore – part 2

I have earlier blogged about setting up a dedicated image server for Sitecore here. The implementation required some customization of the LinkProvider, but from Sitecore 6.3 it is possible to achieve the same just using configuration.

A dedicated media server can be used to serve media on a separate URL, so that you can optimize performance due to limitations on the amount of connections the browser can open to the domain, which I also described in the last post. Further it can be used to optimize your server for handling media and supporting a CDN.

As mentioned it is now possible to have a separate server for media by configuration. In this scenario you might have a dedicated publishing target for media, and this should just be a standard Sitecore installation, which then only handles media by directing the DNS for your image URL to this server. For instance I have setup three Sitecore installations – one as a content manager server, one as the dedicated image server and one as content delivery server. The domain for my content management server is http://sitecore63/, the one for my image server is http://sitecore63imageserver/ and the content delivery server has the domain http://sitecore63cd/. What I then want to achieve is:

  1. That my content management server serves images in the normal way, so that the editors can insert, alter and preview images without having to publish.
  2. On my content delivery servers I want my images to be served by the image server.

The first goal is easy. I just leave every configuration to the standard. This means that the content management server serves media itself.
The second goal requires some configuration changes. On the content delivery servers I must make all media references point to the image server. This can be done by setting the Media.MediaLinkPrefix in the web.config to the domain name of the image server plus the media prefix I want. For instance like this:

<setting name=”Media.MediaLinkPrefix” value=”http://sitecore63imageserver/~/media/” />

This means that all media items on the content delivery server(s) will be prefixed with the above url:

<img width=”128″ height=”128″ alt=”” src=”http://sitecore63imageserver/~/media/Images/user.ashx?w=128&amp;h=128&amp;as=1“>

So in this scenario the html is delivered by http://sitecore63cd and the image is served by http://sitecore63imageserver. In the content management environment, the media is served locally. Now this is a lot easier, than the customization you needed in older versions of Sitecore.

dedicated image server in sitecore

If you want another media prefix then the standard /~/media, you also need to make the media server handle these requests as media. This is done by adding the prefix to the <mediaPrefix> element in the web.config and add the prefix to the customHandlers section in the web.config.


Hidden functionality: The XPath Builder

Maybe it is just me, who never found it, but after a support request I was made aware of a feature in Sitecore, I have missed for years. I thought I’d just share it, if there were any others like me, who wasn’t aware of the great Sitecore application XPath Builder.

Whenever I create a template which uses a Sitecore Query to populate a multilist field with items, I always spend a little too much time figuring out the correct syntax for the Sitecore Query. But no longer… now that I have found the XPath Builder!

The XPath Builder is triggered in the Developer Center through the Tools menu. The application helps you build the right query and shows the result of the query:

Sitecore XPath Builder

The XPath Builder in Sitecore

Yay! What a great tool!