Mark Everard

Hello, I'm Mark – a PhD physicist turned technologist / architect.

Archive for the ‘Opinion’ Category

How exactly do you need to manage your content?

without comments

Detailed content management requirements are often overlooked in the design and build of a content managed website. This can result in an implementation that lacks flexibility and incurs higher costs over its lifetime.

Dual purpose

Web Content Management (WCM/CMS) implementations deliver two key capabilities for an organisation:

  1. A website, perhaps with a new or updated design or brand.
  2. The ability to manage the website content via a content management system

To achieve the best implementation outcome, it is important start your project with design measures and KPI’s that focus on both the success of the website as a business tool, as well as the CMS that enables it. Too often the focus is on just the website, largely because of the difficulty in measuring how well your content management system works for your organisation.

Whether your CMS is effective is rarely immediately apparent, instead it will emerge over time through your content team’s ability to operate autonomously and a reduction in future development need and cost.

A CMS is for life, not just for launch

Even after a successful implementation, it is still easy to overlook your content management requirements. Marketing and campaign-led activity often have bespoke visual needs which can challenge your existing CMS design and content flexibility. They also often come with fixed deadlines and limited opportunity to fully assess the expected campaign content usage and lifespan.

The default position may be to ‘content manage all the things’, but do you really need to?

It is all to easy to build up technical debt within your implementation by designing bespoke types that are so specialised they offer little or no opportunity for reuse. This feature bloat not only increases the size of your code-base, making the landscape more complex for your technical teams. It also makes the system more complex for editorial teams as they have to navigate additional content types. If you have many content types in your CMS that are only used in a few places then you may already be suffering.

Don’t waste time (or money)

To keep on the right track, you should always have your content editing team as a key stakeholder in any website or CMS development. After all, they are the team that will be using any functionality and be responsible for publishing campaign content / functionality on your website through your CMS. It is only sensible that their feedback is taken onboard.

The basics of content reuse requirements aren’t that difficult.:

  1. I need to reuse this content and/or design in many places across the website
  2. I may reuse this content occasionally
  3. I am unlikely to reuse this content, but I need to be able to change it at short notice
  4. I shouldn’t need to change the content. If I do I am happy to rely on techincal support

The answers will drive very different technical solutions, ranging from fully reusable content managed features to a set of static pages to be thrown away after use. The middle ground here is also useful, which allows more technically minded CMS editors and admins to standup flat HTML pages through the CMS interface (an example for Episerver –

The difference in cost and implementation effort can be substantial.

Why spend money and valuable time building reusable content elements for a one-off campaign if you don’t really need to?

Written by mark

February 29th, 2016 at 11:00 am

Posted in C#,EPiServer,Opinion

The real cost of owning a development team

without comments

This post was first published on LinkedIn Pulse on 18th September 2015 –The real cost of owning a development team


Development teams are expensive. There, I said it. If you want a high-performing development team then be prepared to invest.

I’m not just talking about salaries. You’ll also need to equip your team with high-quality hardware and the expensive software tools they need to deliver the solutions you want.

This isn’t news to many organisations. It’s actually not hard to get those bits right, and there are great benefits from having those skills on-tap in-house.

Just putting a bunch of developers in a room, shouting "Go!" and occasionally rewarding with pizza will rarely get you the high-quality solutions you desire.


It’s about the people

What many places struggle to get right is the investment needed in the core of a development team. The people.

Development teams require leadership, mentoring, structured career paths and personal development plans. Just putting a bunch of developers in a room, shouting “Go!” and occasionally rewarding with pizza will rarely get you the high-quality solutions you desire.

Other creative disciplines beyond development perhaps have this slightly easier, as it’s seen as ‘obvious’ that those teams need the room to think and learn.

Take for example a creative design team. They have to work to understand and consume the latest design trends, so they can stay current and produce great work. In my experience this learning need is rarely questioned, perhaps because the design output from those teams is more tangible than the abstract “code” output from a development team. Regardless, the underlying learning need for each team is identical and should be addressed.

Time and direction

The real key to growing your development team is time. This investment allows the team to step back from their primary output and dive into the new technologies and ways of working that could speed up delivery or increase the quality of the technology output. Both valuable outcomes.

Time alone though isn’t enough. You also need leadership and structure. That could be achieved by having a team with a broad mixture of experience, or via a more dedicated architect / lead role helping to bridge the gap between requirements and solutions, helping drive a coherent technology vision.

Again, to those of you working in the industry the above may not seem like rocket science; and really it shouldn’t be. However there are still too many places where there is a attitude of throwing more developers at a problem to get to a solution.

It doesn’t have to be expensive

There are many ideas and ways to give your technology teams the opportunity to learn and improve. Many of them are not as expensive as you might imagine.

  1. On the job training – code / peer reviews are an ideal opportunity to not only increase the quality of the solution but also to share knowledge and build team resilience.
  2. Coding katas – give the team the ability to constantly hone and sharpen their skills by setting aside time for them to regularly practise small development tasks. There are great examples online.
  3. Open source – encourage the team to contribute to an open source project. Here they will learn how to apply their skills in a different environment and learn from fellow contributors. This is even more valuable if your organisation uses open source software. What great karma; to be giving as well as receiving.
  4. Meetups – there are a growing number of outside events encouraging like-minded people to meet up and discuss common skills, techniques and frameworks. Why not encourage your team to participate? Better yet, get them to disseminate what they’ve learnt internally to the rest of the team.
  5. Certification and training – if you have some training budget then paid-for courses not only demonstrate the organisation’s commitment to growing individual skills but are beneficial to your delivery too. Online training courses are relatively cheap and offer a wide variety of subjects.

There’s value to getting it right

Development teams have a very specialised need for learning and growth. Owning a team comes with a heavy responsibility to get this right.

After all, I’m guessing mediocre isn’t your ambition and you want your development team to produce high-quality bug free software? In which case, isn’t it only reasonable to support them and make sure they have everything they need to succeed?

Written by mark

October 7th, 2015 at 10:00 am

Will HTML5 deliver the mobile app-ocalypse?

without comments

Despite the continued success of Apples’ App Store and similar online application stores, publishers are beginning to invest and deliver mobile applications using technologies that many believe may signal the demise of the traditional native app. Is it time to take shelter from an impending mobile app-ocalypse?

With the current popularity of the App Store (over 25 billion downloads) it might not seem like it. However the phenomenal success of the native app market presents a number of problems for both users and publishers alike.

Will HTML5 deliver the mobile app-ocalypse?

The App Store is noisy

There are now over 500,000 apps available on the App Store meaning that finding the latest and greatest is difficult. This can lead to a unhealthy reliance on curated lists and editorially featured content as a means to reliably discover new apps.

As a publisher, this increases the risk that your beautifully created app can sink without trace, no matter how great it really is. This increased competition in the market place also brings out the more nefarious means of grabbing attention. Those user reviews and 5-star ratings are worth real money!

Mobile home screens are overcrowded

Once you’ve found and downloaded the app you want, it has to compete with all of the other apps you’ve downloaded for prime real estate on your device’s home screen. The desktop paradigm that most devices have adopted just doesn’t scale to hundreds of apps. The cost of having to organise, rearrange, update and de-clutter your home screen becomes significant compared to the individual value offered by many of the apps.

Developing for multiple platforms is expensive

Which platforms should you launch your app on? How many versions built on different platforms can your development teams support? Should you try and develop features in parallel across platforms or should you let your feature set diverge and add new features to one platform first? All difficult decisions. It’s pretty clear why there is an imperative to develop with cross-platform mobile frameworks.

Is HTML5 the answer?

No, not in isolation. HTML5 is often misunderstood. It provides an open standards way of marking up data for display as  user interfaces, content and rich media. So the real question is will web apps using HTML5 become the dominant way of delivering mobile functionality? The answer as always lies in the context. If you need to interact with the device hardware then a native app is still the best way to achieve this. If you need to present content, text, images and media then HTML5 and a web app allows you to do this in a cost effective and time-tested way.

There is a third way. Many publishers are now pushing a hybrid approach and realising significant cost savings across mobile channels by building native apps which use HTML5 to deliver user interfaces that are imperceivably different to those offered by native code. Take for example, the latest LinkedIn IPad app which to many commentator’s surprise delivers 95% of it’s views using HTML5 (and of course a hefty dose of JavaScript and server-side data services).


Native apps won’t disappear but clearly there is convergence between the experiences native apps can deliver and those available via a browser.

Perhaps though it’s the app delivery mechanism that will change most of all. Rather than investing time up-front collecting apps from a store (with a vastly improved app discovery mechanism), perhaps apps will be downloaded only if and when you need them. This is the exact model suggested by ex-Apple and Google mobile UX guru Scott Jenson who suggests that future apps will be delivered ‘just-in-time’, installing only the features you need there and then. The underlying technology for such delivery is already available. It’s the web!

Here for the long run

Ultimately, reports on the death of native mobile apps have been greatly exaggerated, but HTML5 shows every sign of becoming the dominant cross-platform technology for serving rich interfaces, media and content.

Every future device of note will have a standards compliant browser, meaning that every device will be capable of consuming content and services delivered in HTML. As a publisher or developer it would be foolish to ignore this. As a user, hopefully you won’t even notice the difference…..

Written by mark

May 16th, 2012 at 4:02 pm

Posted in iOS,Mobile,Opinion

This time……………….

without comments

This time

This isn’t mine – in fact I don’t know who the credit should go to. However, it was so great I wanted to put it somewhere relevant where I could see it often.

UPDATE (16th May 2012): It originally came Manu Cornet at Bonkers World. Awesome stuff



Written by mark

April 18th, 2012 at 2:10 pm

Posted in Opinion

GiveCamp UK – a philanthropic software development microcosm

with 2 comments

I was lucky enough to participate in the first UK GiveCamp over the course of the last weekend.

Wow, what an incredible experience!

“Pair 120 developers with a collection of UK charities each with an IT need. Lock them in a room, feed with caffeine, cooked pig and sugar. Leave to bake over the course of a weekend, peel open (and off the floor) on Sunday afternoon. Stand back and view the results.”

The concept, execution and community was superb (see @stack72’s post for a great list of thanks to those involved). A special thanks must also go to UCL for hosting the event and the generous sponsors for providing financial support and goodies! Come the Sunday afternoon ‘show and tell’, all of the project teams delivered some great work, much of which will make a tangible difference to each of the UK charities that got involved.

“For the first time in living memory, someone cried because the software we did was so good.”

What better testimonial than this? How many times have you had this reaction whilst working in your day job 😉

GiveCamp UK 2011

GiveCamp UK 2011 - photo by Bert Craven

A software development microcosm

Whilst the time-scales involved in GiveCamp make it an unreal experience, at the end of the day it’s just software development, and so the normal rules and pitfalls of software development apply.

The thing that really struck me whilst working, is that is that it’s very easy to get carried away and lose focus from the end output. Whilst much of this could be attributed to the excitement, intensity (and tiredness) that surrounds the event. Actually it is just par for the (software development) course.

If you’re ever involved in a future GiveCamp (and by all means you should), here are some of my top tips……

Deliver deliver deliver

Don’t overreach and try to build the Tower of Babel. Solving one problem well, is better than half solving many problems.

This means you constantly have to question the solution to make sure that every design decision that is made, is made for the right reasons. Do you really need that level of granular security or additional view? Focus on your core functionality only.

Remember building ‘cool’ stuff is not the output you’re looking for. Delivering a working solution that solves a real world problem is the ONLY goal….


As ever, it is important that you have a engaged stakeholder / product owner – who is actively available to field questions and define their needs (we all know this from our day jobs right?)

Remember though, the charities will be like a kid in a sweetshop – whilst you are their ‘knight in shining armour’. It’s ok to question their requirement wish-list. 41 hours is not a long time to deliver a solution. So always make sure you stay focussed on solving a real and well defined problem.

Keep it simple stupid

After the weekend, the solutions are handed over lock and key to the charities. You need to make sure they know what you’ve built for them and that they have enough information to support it going forwards. This could mean documentation! One team produced a 40 page document on how to install a SQL Server instance. The time spent on that document was way more important than any one additional software feature. Without it, the solution wouldn’t have even been deployed.

Remember – not everybody knows the things you as a developer takes for granted. Imagine that you’re delivering a solution for your dear Nan. That’s the level you should aim for.

Focus on what you know

When you’re under pressure to deliver, don’t go off-piste and make some ‘left-field’ technology choices, so you can learn the latest new and shiny thing. Stick with what you know and what your team has capabilities with. Don’t worry, they’ll still be plenty of opportunity to learn.

For me I was working with ASP.NET / MVC but I still learnt more about Git, Entity Framework and what an awesome service AppHarbor provide.

Future me

I definitely wish I’d had ‘future me’, looking over my shoulder to remind of those things throughout the weekend (especially at 2am on Sunday morning when the adrenaline was wearing thin). However I also know that ‘future me’ would have told me how proud he was of all of us who donated time and effort to help out.

Top stuff to all involved. Here’s to GiveCamp UK 2012!

Written by mark

October 26th, 2011 at 2:00 am

Posted in Code,Community,Opinion

What are you going to do about it?

without comments

As programmers, we’re very used to dealing with systems that are easy to understand and behave predictably (though I have worked with some codebases that are the exact opposite).

Aside from code, the majority of our day-to-day interactions in the workplace are with team members, managers, clients and other colleagues. These human interactions are often much harder to predict and respond to, but can have a much greater impact on your work environment, productivity and workplace happiness.

I attended Roy Osherove’s ‘Lead Better London’ course held at Skills Matter back in July (and have been meaning to post a follow up about it ever since). Roy was / is a leading voice in the .NET community (though now he’s exploring what Ruby has to offer) and is the author of ‘The Art of Unit Testing‘, which I consider to be THE book to read if you want to learn and become better at writing test code for your software. Roy regularly blogs about software team leadership issues over on, and it is from there where I found out about the course.

The 2-day course caught my eye, as it was focussed on managing people and software teams rather than any specific project methodology, such as agile. Courses such as these give you a great opportunity to take a step back and view your workplace and your interactions within it in a different light, without the distraction of your ‘real work’. Roy is a great mentor and from the off, ably demonstrated the ‘ninja’ leadership techniques he was trying to teach to us. His ability to listen, comprehend and consolidate a problem down to a fundamental is a skill I really want to perfect.

Things I took home with me from the course:

  • Confidence to Lead: motivation to tackle the issues I see day-to-day in my workplace
  • How I react: ability to recognise my own and my colleagues behavioural traits and adjust my response to suit
  • Who I want to be: a clearer idea of the characteristics I believe make a good leader and the willpower to make sure I follow the right path.

The plural of Lego is Lego, not Legos. The word Lego is a trademark and should be used as such. Here is a picture of some Lego bricks.

Roy is holding another course in London this November (2011) , so if you’re interested in learning how to lead and grow a software team, then you should do what you need to do to get yourself on his course.

For me, the challenge now is to take the skills I’ve learnt and put them into practise in my day-to-day work life.

Let the human experiment begin……

Written by mark

September 12th, 2011 at 11:00 am

Posted in Code,Opinion

Future ASP.NET features for UID / HTML developers

without comments

Slides for a talk I gave to Fortune Cookie’s HTML developers, where I tried to press the following points:

1) WebForms != ASP.NET
2) MVC FTW 🙂

Written by mark

September 17th, 2010 at 12:11 am

Posted in ASP.NET,Opinion

Maintaining a successful software platform

without comments

There have been a few scenarios played out recently that have got me thinking about ‘the effort required to maintain and drive a successful software platform’. Its clearly a difficult balancing act as not only do you have to develop a product with the functionality that end users desire, you also have to create a ecosystem of developers who are able to leverage your platform to create cool products!

Apple’s very public spat with Adobe over Flash support clearly demonstrates the difficulties with maintaining the right balance between the end-user and developer. Apple’s heavy handed approach to setting their strategic technological vision for the ‘good’ of iPhone / iPad user experience has ostracised a large section of experienced rich-interface developers, who were excited at the steps that Adobe had taken to enable their ideas on the Apple platform. Whether or not this was the correct call from Apple will only be borne out in time. If I were Adobe, I’d be throwing my weight behind Android and creating some great Flash development tools in the hope that Flash developers produce the killer apps to show that Flash on a mobile is a ‘workable’ technology.

Microsoft have been taking a different approach in recent years. Its latest successes (I’m not including Windows 7 in this – in fact, is that even considered a success?) are built on the foundations of the .NET platform, and have been driven entirely by a open, honest focus on developers and empowering them by giving them access to the best development tools (seriously Visual Studio is an amazing bit of kit). Their approach to Windows Mobile confirms their belief in this methodology. Stuck with a mobile offering that paled in comparison to competitors, they went away for a while, re-thought their whole approach (undoubtedly influenced by Apple’s App store success) and created Windows Mobile 7. In one swift announcement they turned me (and any other .NET developer) into a mobile developer. It will be interesting to see whether they can deliver an end-product that stands up too.

Being able to throw away a partially-successful platform and start again is a luxury that only the major players like Microsoft, Google, Apple can afford to do. Most smaller platform vendors can’t justify starting over from scratch. In fact, doing so could be the the single worst strategic decision they could make.

Instead the only choice left is to evolve and work extra-hard to improve the areas that need the most attention. The first step towards any solution is always admitting the problem.

An error doesn’t become a mistake until you refuse to correct it.

Orlando A. Battista

This then brings us back to the original conundrum. Where do you focus your development efforts? Who really is the most important user of your platform? Developer or end-user?

Renowned CMS anti-hero @McBoof approached these issues with his challenge to CMS vendors to rate the following CMS ‘features’ in order of priority:

  • Editors – A user interface that is a editor or publisher’s wet dream
  • Performance – The fastest, most stable and scalable CMS in the world
  • Features – The richest set of features any CMS could dream of offering
  • Developers – An open, standard, extensible product that makes developers salivate
  • Website – A product that can give you a kick-ass website, really really quickly

What the results of this semi-serious survey actually tell you is open to debate….. but what is clear is that none of the CMS platforms mentioned excel across all areas. Simple rule of life: You can’t please all of the people all of the time!

Speaking as a developer, I obviously want to use tools and APIs that help me create solid, maintainable code and that generally means using the newest technology (ORM’s, Dependency injection, etc etc).

However I’m also aware that adding new features/APIs to existing platforms takes time and some features may rightly or wrongly not be considered a priority. For example, how long has it taken Microsoft to allow developers full control over rendered client Ids in WebForms? A well-known ASP.NET limitation which has been the bane of every front-end developer since the dawn of time (aka VBScript). Taken in isolation this didn’t make .NET a bad platform, just a slightly less perfect one.

This is where (as @joelabrahamsson pointed out on my last post) the development community should take the lead and not only point out any issues to the platform providers but also attempt to show the way and to provide sensible solutions/fixes to any issues that may be causing development woe.

This shouldn’t be a one way relationship. In return, a developer should expect open discourse and two way communication with the platform providers. Sharing things such as a development roadmap allows developers to make up their own mind about the platform’s direction and to have input on the proposed pathway. Any contentious proposals will soon be flagged up by the eager community, giving a chance to either re-think or to justify the initial line of thinking, as Apple’s Steve Jobs attempted with his ‘Thoughts on Flash’ open letter.

To me – that openness is the key to a successful platform. It gives great buy-in to the potential developer knowing that they can shape not only their end product but also help to shape the future of the entire platform.

Written by mark

May 6th, 2010 at 9:12 pm

Posted in Opinion

The Great EPiServer Informed Response

without comments

Some of you may have picked up on a blog post entitled the ‘Great EPiServer Rant‘ posted by Fredrik Holmström. I’d encourage you to read it for yourself and see what you think.

If you find yourself agreeing with Fredrik, then please read on, as the EPiServer developer community have made great strides in the past year improving the same aspects that Fredrik finds annoying.

I’ve listed some direct responses to the points Fredrik made in his post. I’d welcome your comments.

The Development Process

Any EPiServer developer will recognise and remember the frustrations that came from having to manually add and update PageTypes in the database especially when working across several environments. It was a royal pain, but not any more. The EPiServer development process has moved on.

I just cannot imagine starting any new EPiServer project without using PageTypeBuilder (by Joel Abrahamsson), which decouples your code from the EPiServer database, and in one fell swoop does away with any need for workarounds and central ‘development databases’. This tool has been actively developed and blogged about since June 2009. Its an invaluable tool for any new EPiServer project. Look into it and if you choose to ignore it… well, good luck.

Everything isn’t a page

I couldn’t agree more, accurately distilling requirements down into a sensible domain model is a non-trivial problem during any software design phase. It brings to mind the following quote:

Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful

George E. P. Box from Box and Draper, Empirical Model-Building, p. 74

Surely a content management system using a domain model based on the concept of pages is reasonable? It has its limitations sure, but there are sensible ways available to extend this model. The latest version of EPiServer (CMS 6) has introduced the dynamic data store, an API that allows the storage and retrieval of arbitrary data structures. Further still, these can be linked directly with the overriding page model via the Page Objects extension API.

If you still feel like you’re having to push a 50″ square through a 2″ round hole then frankly you’re doing it wrong. Perhaps EPiServer wasn’t the right CMS system for your project? Perhaps you are trying too hard to utilise a CMS to store alternative business data that shouldn’t fall under the remit of a CMS?

Is it really fair to judge a piece of software by what it can’t do rather than what it can? EPiServer won’t meet your requirements as a business accounting and reporting system but as a Web Content Management system it certainly can.

There is no spoon (or documentation)

The available EPiServer documentation has improved immeasurably over the past two years, but thats not to say it can’t improve further. Much of the improvement has come from the developer community who are invited to allow their content to be aggregated into the EPiServer World site. If you follow this then you’d surely have seen many great posts by interested EPiServer developers and in particular you couldn’t have failed to notice Frederik Vig’s excellent series from December 2009 entitled ‘Creating an EPiServer Site from Scratch‘, which should be considered the starting point for any developer new to the EPiServer platform.

Agile – is that a cactus or something?

TDD is an extremely valuable approach and certainly isn’t impossible to do with EPiServer. The EPiAbstractions framework (credit Joel Abrahamsson) is a library of facades that wrap the core EPiServer classes and exposes virtual methods so you can mock, isolate and test to your heart’s content.

However the difficulties in using TDD within an EPiServer project aren’t limited to the EPiServer API. They are passed down from the ASP.NET WebForms framework itself, which is incredibly difficult to unit test because of the strict dependency that the codebehind file has on the HttpContext.

Again however there are viable solutions available. One such is the WebForms MVP framework (of which EPiServer already has its own version – EPiMVP – thanks again Joel), which facilitates a better separation of concerns between UI and domain level logic. This enables you to say hello to niceties such as Dependency Injection and other methodologies that facilitate code testing.


In the two years I’ve been an EPiServer developer,  there has been a noticeable shift from EPiServer towards fostering a strong developer community. This has paid dividends, as the community has provided a great number of excellent blog posts/solutions that have truly improved the EPiServer development experience.

The continued interest in EPiServer WCM products from potential customers demonstrates that a great many developers are successfully delivering high-quality WCM solutions using the EPiServer platform. With the continued input from the community, I’m sure this will continue.

Put simply:

Happy developers = Successful implementations = Happy customers

*(and yes, you can put me down as a happy developer!)

Written by mark

April 20th, 2010 at 2:30 pm