Sitecore xDB Personalisation at the client

Nick Hills’ headed over to SUGCON last week to share his infinite wisdom with the rest of the Sitecore community, if you missed it or want a recap you can listen to his talk below:

This talk shows off techniques that allow you to combine two great tools: the personalisation capabilities and power of xDB along with the benefits of CDN edge-caching. Editors can configure and design personalisation rules as normal yet still harness all the power and gains that CDN’s offer.

He’s also handily put together a whitepaper weighing up the pros and cons of the various approaches –

Get in touch if you want to find out more on +44 (0)117 932 7700 or

Graduating Soon?


We love hiring graduates!

We hire a lot and we’re getting pretty good at training them…

Over 50% of our company joined us straight out of Uni. Last year we have had 7 graduates join us in Development, Test and Project Management. Some of the developers we hired as graduates 10 years ago are still with us , including two of the computer scientists we first met at Bristol University, who are now Sitecore MVPs (an award given to only 0.53% of the Sitecore certified ecosystem).

Our graduate recruitment is under way and we are keen to see applications from budding software developers who would like to work in Bristol.

We’ll be at on the 8th May, come and say hello to me (and some of the team) to find out more.

If you can’t make it, feel free to drop me a line for an initial conversation about the roles on 0117 932 7700 or alternatively send a copy of your CV to:

Commerce and Digital Content Event

Feels like the year has just started but we’re over a month in and we’ve already held our first event.

The event was a great success, it was oversubscribed and we had a great list of brands speaking and attending. For those who missed out, or those who asked for the slides you can grab them below:

Econsultancy – The digital retailer, trends, opportunities and challenges

Fenwick – Avoiding creating content for vanity’s sake

Quill – Using e-commerce content to power growth

JLL – Food in fashion, a newsjacking case study

Now to get planning the next one 🙂

January 28th event – Commerce and Digital Content, Trends, successes and what to avoid

Ciprian Muresan - THE UNBELONGING

We invite you to hear from our panel of digital marketing experts on whether editorial content really is all it’s cracked up to be in driving web traffic and sales. Come and join in the discussion on their experiences across a variety of sectors including retail, fashion, travel, media and leisure.

Running Order: 

  • 13:00-14:00: Arrivals, lunch and drinks
  • 14:00-14:10: Welcome note
  • 14:10-14:30: Econsultancy, “The Digital Retailer: Trends, Opportunities and Challenges”
  • 14:30-14:50: Fenwick, “Avoiding creating content for vanity’s sake”
  • 14:50-15:10: Quill, “Using ecommerce content to power growth”
  • 15:10-15:30: JLL, “Food in Fashion” A newsjacking case study
  • 15:30-15:50: Panel Q&A, “Where should you be putting your efforts?”
  • 16:00-onwards: Networking and drinks

Who should come?

The event is aimed at sharing experiences across sectors from people who are responsible for driving their online sales and strategy. Heads of/Managers of – Digital, E-commerce, IT and Marketing will get the first pick of tickets.

Register now:

We hope to see you there!

Sitecore 8.1 – What you need to know from those who know best

The Sitecore experts (MVPs) were lucky enough to get their hands on XP 8.1 two months before it was publicly released in October 2015. The early access allows them to get a head start on mastering the new release and provide Sitecore with essential feedback for improvements and the roadmap. As part of this Sitecore have released a whitepaper on the MVP’s initial reactions to three questions:

  1. What’s your favorite feature of Sitecore XP 8.1, e.g., what part do you think businesses couldn’t live without?
  2. What in your opinion is the greatest benefit of Sitecore XP 8.1 for digital technologists and IT leaders?
  3. What in your opinion is the greatest benefit of Sitecore XP 8.1 for developers?

You can grab your copy here. We’re pretty p

True Clarity at the MVP Summit

Here at True Clarity we are lucky enough to have three MVPs… all Sitecore nerds! As you can imagine the chance to visit New Orleans and be part of the MVP Summit was one we all jumped at when True Clarity offered to fund the trip. A massive thank you to the company.

Over 90 out of 167 recognised MVPs attended the event, which is a whole host of Sitecore love and brain power in one room! The impressive turnout really does show the enthusiasm all the MVPs have for the platform.

I had high hopes for the event especially after seeing the agenda for the two days. The welcome drinks, canapés and chance to network with the other MVPs the night before the summit was excellent, but the real business started on Tuesday. We were lucky enough to see Sitecore’s vision of the future and the road map for the next year or so first-hand. This really is one of the main reasons I wanted to become an MVP, to get involved and engrossed with the future direction of Sitecore in some capacity. I was not let down.

Day 1

The Tuesday sessions kicked off with an introduction by Pieter Brinkman, a video containing some captivating music and a swarm of numbers showing the appreciation Sitecore has for its MVPs, which as you can imagine got us all buzzing. Did you know that the MVPs, (a group of just 0.53% of the Sitecore certified community) contribute to over 50% of blog Posts, presentations and Sitecore modules?

The real “Strap in, hold on, because this is where the technology is going” ride started with a great talk by Todd Mitchell on xDB vNext and Brandon Hubbard who shared (top secret) plans for Speak 2.0 something, which I really feel is going to be huge when it hits the masses.

We also heard some (again top secret) insights into the next couple of Sitecore releases by Kern and Stephen Pope. Some really exciting features in the pipeline, both for developers and end users to get excited about.

I was exhausted after all that but quickly reminded we had a swamp to tour, alligators to feed, cigars to smoke and moonshine to drink – It’s safe to say Sitecore can put on a party!

Day 2

The “I attended breakfast” achievement badge (MVPs love achievements it seems) never had so much significance as it did the morning after the swamps. Everyone still turned up, not wanting to miss the final day of the summit.

The real highlight of the summit for me was on day two. Fan favourites Kern and Stephen Pope were back for a talk on the future of the core of the platform. Following the common theme of ‘top secret – please do not share anything’, I’m going to stay vague but I was blown away with the plans Sitecore (and in particular Stephen and Kern) had for the future of the platform. The amount of time afforded to listen and discuss the MVPs opinions was also fantastic – I think by the end everyone in the room was on the same page and thinking “Wow this is going to be great… but let me have it now!”

Other highlights included the opportunity for us MVPs to have round table discussions with Sitecore staff about specific requirements or wishes we had for the platform. I think we managed to convince Stephen to include about two hundred ‘essential’ features into the next release (he did have his fingers crossed) but it’s great to see the platform moving in the direction it is following feedback from the MVPs – feedback Sitecore obviously value.

Being a MVP newbie myself (first year as an MVP) the summit completely convinced me (not that I really needed to be) that Sitecore continue to move in the right direction. These are exciting times for a number of different areas within the platform. The benefits to developers, marketers, content editors, well… literally every Sitecore user has the potential to be huge, and it was amazing to see and be involved in these plans first hand.

Thank you Sitecore!

When code is considered technical debt

I have spent a while considering what technical debt is and concluded there is no good definition that is particularly useful to estimate the problem. Instead it is more practical to understand when code should be considered technical debt as this is more useful. Many people don’t know when to tackle technical debt and often choose to tackle it at the wrong time.

It’s common to hear people talking about technical debt as either code which is hard to maintain or code which does not conform to their idea of good code. Fashionable best practices often influence the latter. I will use these two ideas to loosely define technical debt. I believe there isn’t a definition that can quantify debt absolutely, so I’ll use a reasonably simple definition that mirrors how developers think about it in the real world.

At True Clarity we have several separate teams all working on enterprise web applications using fashionable best practices. Each team has roughly the same distribution of skills and experience and equally challenging work. I have reviewing each team’s code many times and each team does have markedly different levels of technical debt.

The interesting thing is that all teams have a reasonably close level of productivity.

I have made similar observations throughout my career. The complexity of the code is often not a contributing factor to productivity. My hypothesis is that familiarity of the code you are working on negates technical debt being a problem. Put another way: the impact of technical debt is inversely related to the familiarity of the debt.

This leads to some interesting conclusion:

  • If you have never seen a particular code base before you are more likely to be unproductive and you are more likely to feel like there is technical debt.
  • If a code base does not use the coding practices you believe are “best”, it is less likely to seem familiar and therefore you will think it is technical debt.

This highlights the high degree of coupling between productivity and our natural familiarity with something. This statement is obvious in itself, but with code, people seem to forget it.

Another observation at True Clarity is that a team tends to be at its least productivity when we put a brand new person on that team. How quickly that person gets up to speed depends on how easy the code is to read and make changes to (factors like how much time colleagues spend helping the person tend to be equal among the teams).

This means we pay the greatest interest on technical debt when people are new to the code they are working on. This is a pretty consistent observation, and I haven’t seen contrary behaviour (taking motivation out of the equation).

It turns out it is not always observed that you pay interest on technical debt when working on complicated code. It can be quicker to make changes to complicated code if you know what it is doing (because it may support what you want to do quite easily if you have the know how).

Ultimately, you have to decide how often people will be working on unfamiliar code to get a good measure of the true size of technical debt.

The tipping point for tackling technical debt

This actually means there is a tipping point for deciding when, if at all, to tackle technical debt. Let’s say you seldom work on an area of code, but when you do it is very time consuming. Is the cost of rewriting that code greater than the time spent updating it when you need to? That is a question an architect should be having with the business.

So far so bleak, but we can also draw some very positive observations.

If a team spends extra effort making highly readable and maintainable code it often gets a productivity boost that offsets this extra effort. At True Clarity we have never seen a team go much beyond break-even in terms of payback on productivity, however, the ability for new people to get up to speed is very rapid so we have seen good payback in this respect.

To start to tackle technical debt, evaluating the tipping point (when it becomes valuable to the business to rework “bad” code) is the key. By conceptually dividing your code base into the small modular areas you can determine the tipping point of each area. If you are a developer or architect that genuinely understands what is important to the business you may have autonomy to choose when to rewrite code. In the case where you have autonomy you can make those decisions at a very granular level (on a file or method/function level for instance).

Out of interest there is an alternative solution to technical debt: refine your project induction process. By this I mean the human element of induction like coaching and mentoring (i.e. get better at explaining your own software by explaining often and refining your own understanding). Something that documentation can’t replace is learning to communicate your domain expertise to different audiences (after all not all developers need the same information or process information in the same way). I will discuss documentation in another post, the short story is there is a tipping point where documentation becomes debt so it needs care. After all, once a person is familiar with code the interest on technical debt diminishes. This may be a solution if your team is volatile and you don’t know where to start on your debt problem.

Take care rewriting technical debt

I will leave you with one caveat to rewriting code that is another consequence of the fact familiarity reduces debt. Often a developer will rewrite something that makes more sense to them, but another developer will look at the old version and the new version and think there is no improvement. The process of rewriting gives you instant familiarity, therefore leading you into a false sense of “solving” the debt. Unfortunately you have only solved it for yourself, you have not helped the business one bit. Another instance of this is rewriting something using a fashionable new technology where people will immediately feel more at home with the code. This is legitimate as it will help people gain quicker familiarity. The true goal, however, is to make the code really readable without relying on fashionable coding tools/techniques. This involves a real understanding of the cognitive friction involved in a person reading code and extrapolating the business requirements from it. Ultimately, you should be concerned with how easily someone can relate your abstract model to the real world. I have found this last question leads to a satisfactory definition of debt as a cognitive relationship rather than a technical standpoint.


Evolving the Complex Customer Experience

In the beginning websites had one thing to do and they needed to do it well. Whether it be selling the latest pair of shoes to a fashion conscious 20 something, or letting someone book a European flight from Bristol to Barcelona. With these single-minded user journeys the processes that grew up in the digital world work well. Design, test, build and deploy. Then optimise with more testing.

In the landscape of possible solutions this approach is pretty much guaranteed to get you to the top of the mountain in shortest amount of time. Efficient optimisation.

The game has changed.

It started innocently enough. The on-line fashion retailer wants to become a destination. Mixing editorial fashion news in with the product offerings. The airline wants to tackle those who just want a deal, not knowing exactly where or when they want to go.

To start with the solution is simple. Create distinct areas of the site for each specific user journey. When a customer needs to shop, send them directly to the shop. When they want to browse the news then they go to the news section. When a customer wants a flight from A to B then use the search tool. If they want to browse around go to the interactive map experience. Great our methods of optimisation continue to work as the two user journeys are independent. When you examine each user journey in isolation your old methods for optimising the experience do still appear to work.

However when you look at the bigger picture you can see something isn’t right. Customers are people after all and people don’t like being put in boxes. Someone reading an article on Rihanna wearing fuchsia will want to go buy something in fushsia. The customers who hits the site with a definite idea of where to go, change their mind and want to be inspired. The new customer journeys are interdependent. Changing one will have an effect on the other and visa versa. Chances are you won’t even have just two journeys to consider.

Science has a word for systems that have a high degree of interdependence. Complexity. Solving problems when things get complex is not straight forward. Just look at the weather. That’s an interdependent system with each weather system both effecting others and being effected by others. Even with massive super computers we can only make short-term predictions about the weather. The same goes for these complex customer experiences.

There is one strategy that works well with this kind of complexity. Evolution. Life has been dealing with the problem of complexity by letting solutions emerge. How do we apply evolution to a highly interdependent customer experience?

As with evolution the answer lies in building blocks. Small components that can be rapidly combined. Allowing the high-level customer experience to be tested in the wild. Winning combinations of components get to fight another day. The winners get combined and mutated slightly before being tested again. While each component will need designing and building. The cost of combining the components on the page needs to be low. Only then will the next generation of complex customer experiences emerge.

A Place in London

It’s been a while coming and we are finally here, we’re properly in London, in Kings Cross to be exact. 344 Grays Inn Road to be exacter. Our very own capital oasis of calm productivity.

Until now, away from our Bristol office, we’ve been working on site in our London clients’ offices, taking up their space and drinking their tea. We still do that when necessary of course but now we also have our very own development, training and work area. And our own tea.

It’s a place that’s no more that 30 minutes from our Sitecore clients including ASOS, The Conservative Party and WaterAid.
A place place people want to go to work and maintain and improve our Sitecore productivity.
A place we can call Work. In London.


PS We’ve just hired yet another London Developer so that’s seven of us here permanently. Bristol, we’re catching you up 😉 We’re looking for more Developers (ideally with Sitecore experience). If you want to work with us and our clients, and you’re not a recruitment agency, please give me a call on 020 3428 6841.