Getting the technical and creative skills balance right for website design

Or... why we have a love/hate relationship with Rubik’s Cubes?

OK, we don’t hate them, in fact we should probably be grateful to this 80s icon since we’ve won a lot of business recently because of it. However, when it comes to developing websites (or any type of software) we have to bury the Rubik’s Cubes. Let me explain….

Technical agencies, such as ourselves are often too quickly regarded as not creative. This can feel unfair and too hasty because we have seen some fantastic creative work from technical agencies over the years.  It’s just that the strength of this type of agency is more in technical creativity, this blends all of these factors:

The elegance of the solution... The interaction design of the page (helping bring it to life from a static comp produced by a creative team). The integration of the solution into CRM systems and complex legacy IT platforms to create beautiful digital architecture. All of these things are fantastically creative.

However, the external perception of technical teams is that we are 'just the build guys'. The technical partner is often perceived to add the lowest value. Perhaps that was true 15 years ago when we started building static HTML websites but crafting beautifully architected solutions which support customer journeys and experiences is now vital.

The need to get to market quickly and then make rapid, iterative updates to a solution is crucial in a world where agile software development is king and traditional 'waterfall' approaches are no longer fit for purpose (perhaps the subject of another blog!).

The demise of traditional development techniques means that lengthy 'testing phases' are a thing of the past. We need to be able to update complex marketing and e-commerce sites weekly and even daily.

How do technical agencies show their creativity?

So how do technical agencies convince their clients that they are not just 'the build guys' but a highly technically creative partner whose agile development processes are vital to their digital success? Well, this is where the Rubik’s Cube makes its entrance.

So where does Rubik's Cube fit in?

Here’s the analogy that we use. We ask clients whether they have any legacy platforms or websites within the organisation that are like playing with a Rubik’s Cube?

After looking at their confused expressions for a second, we explain what we mean. We ask whether they have any digital projects where every time they add a new feature or fix a bug (and get one side of the Rubik’s Cube all lined up) sometime later (could be days, weeks, even months after the update went live!) somebody realises that something on one of the other sides of the Rubik’s Cube is broken.

Everybody who’s been involved in any type of online development over the last 10 years in any large organisations always grins knowingly and nods their head whilst we make this analogy. It’s a nightmare but what can be done?

You can’t test every aspect of an enormous system every time a small change is made. You’re stuck with a Rubik’s Cube playing with it almost blind folded and struggling on in the vain hope that one day all the sides might line up and nobody will ever ask for a change ever again. But you know this will never happen.

Perhaps 'how do you fix a Rubik’s Cube?' should be the subject of another blog post. There is stuff you can do but let’s leave that for another day. This blog is a call to action to stop building them in the first place.

The solution is automated testing through a solid continuous integration process along with continuous deployment.

What the hell does that mean? We are happy to show anyone who cares a bunch of complex looking diagrams (that really aren’t that complex!). However, we predict that you are probably not going to be banging on our door for these so we’ll explain what it means.

• Every time any developer on the project pushes up new code, a whole bunch of tests which check the logic of the code are run to make sure that no errors have been introduced.Not just the code they have written (for which they will have written some new tests) but all the code across the website to ensure that what they have just done has not broken anything else.This is called unit testing and it is vital that this is done as an absolute minimum on any project. Yes, it takes a little longer than not bothering at all but I promise you will get that time back many times over in the future by avoiding the Rubik’s Cube.
• Only once ALL the unit tests have passed is anything deployed (though an automated 'Continuous Deployment' process) to a development environment.On top of this, most of our projects will build up a set of 'selenium' tests. Whilst unit tests cover underlying logic these are scripts that can automatically launch a browser and 'click' round the website checking that everything is working ok. Does your site have a login that gives access to a members area? Great.
  

  Create a simple selenium script that logs into the site and checks that the content is available as it should be. If anyone on the project ever does anything that accidentally damages the members login feature the team will be automatically notified the minute it hits the development environment.

Our approach (and there are lots more things we can do than those described above!) doesn’t eliminate bugs and mistakes completely of course. However, it does give the team a huge amount more confidence when making rapid updates to even very large websites and applications. The team doesn’t have to worry that they have broken any major functionality. That feeling that you are handling a Rubik’s Cube is gone. And it feels great.

So here is my plea. If the Rubik’s Cube sounds familiar, come and talk to us about how we can help or at least make sure you are challenging your build teams to be working in this way. We have to stop building complex systems without good levels of automated testing in place. I really hope I'm not having this rant again in 10 years’ time.