Here is something that I have found all too often in my career working with a multitude of CMS systems, and it is this :-
Sitecore is not a product that you can build for a customer and then forget about, customers to get the best from their solutions should be hand held, communicated with, and as developers / vendors – this provides long term work opportunity. It is all to often that (especially in the Digital Media Agency environments) I find Developers blindly following a spec (often written by someone who does not know the framework) and not considering the bigger / long term picture. In my experience, this often leads to a lot of work later that would have been next to no work during the original implementation.
In my post on The parallels between single language and multi-language developments I covered just such a question. It eludes to statements you will often here from clients which could include (but far from limited to), things like:
- We will only ever have an English site
- We will only ever run one site on our Sitecore solution
- We will always use workflow
Our journey in development should always be governed by a mix of knowledge gained through a variety of mediums, the fact you are even reading this post suggests you are eager to learn more about the product(s) you work with. This added to your own experience and the shared experience of your wider team should lead to you making ever increasingly better decisions with each solution you build. So my responses (based on my own experience and in my head) to this are usually something along the lines of:
- Really…..? Your ‘massive’ brand that you have sold us on since the pitching process has no plans to EVER consider beyond the English market?
- Ok – so your CEO is going to build your brand and sit on their ass and watch the money fly in without thinking – ‘hey we could make some more by..’
- You really haven’t thought about basics like – every image, every tiny translation change… well just… EVERY CHANGE! It’s great that some clients have vast content entry teams with the resources to achieve this. Many clients though will end up with an army wanting ammo and a single guy with the keys to the ammo store (chips down – that guy is gonna get a beating).
The above are all examples of me using my experience / knowledge to question whether the decisions that have been made (often in the developers absence and often by sales / accounts folk) will actually hold up.
How do these decisions affect us
In short, this is often the answer to the unknown questions and the argument isn’t really so much about how / what will happen if we don’t. The Agile principle of building only what is needed should still be ahered to, at the same time we should try to follow almost the same design principles as are prevalent in Object Oriented Programming as a whole. This helps to allow the client to change their mind.
Consider things like SOLID applied to Sitecore (in essence if not strict):
- (S)ingle Responsibility -> This can be applied to loads of issues – renderings should have a single purpose, as should pipelines / commands.
- (O)pen Closed Principle -> If you base your code on template id’s / names (described here) you will have to change that code to ever extend upon it.
- (L)iskov Substitution Principle -> Pipelines / Datasources, you name it, they should be replaceable
- (I)nterface Segregation Principle -> Multiple small templates are better than single bigger templates
- (D)ependency Injection Principle -> You want to reuse your controls – use data sources. Also resolve your pipelines / commands / view models etc from IoC containers if you can
The essence is still pretty much the same.
Unfortunately, sometimes developers don’t get to see a ‘longer term’ view of their solutions in the wild, which sometimes leads them to make the same decisions over and over. Sometimes it may be that the people doing the selling are not familiar enough with the challenges Sitecore solutions present. The whole of this series has been dedicated to identifying issues that have arisen in these longer term scenarios. Hopefully part of the series will help even if you don’t work with clients on a longer term basis.
To this end QUESTION – yourself, your piers, your accounts people, your sales people. Most clients have to live with your solution for years and you will add the best value to their business and your own by thinking about the bigger picture without holding yourself to it.
This article is part of the Don’t Fight The Framework Series