Well technically it has already started, but the conference proper kicks off tomorrow and there are some awesome sessions lined up.

My talk is coming along, a challenge, but a fun one.

Personally I am looking forward to both talks by Michael T Nygard, however choosing other talks will be a difficult with so many interesting parallel tracks.

See you there.

I will be speaking at QCon London again this year, this time on the London Startup track on the topic of Lean.

It will be a big challenge to do justice to both the subject and what I’ve learnt over the last few years but I am looking forward to it.

It’s most likely known by other names, but this is the one I used to describe the idea to colleagues.

We had a service that exposed a HTTP api, however the service had become brittle and hard to extend or modify. However we needed to make additions quickly, the overheads and risks of change to the original service meant comtemplating a rewrite, something we avoid.

There is another option, that is not to touch the existing system but rather apply a facade or a lightweight proxy in front of the system. Using this facade you can either direct calls to the original system, handle them directly or even pass off to a new system. HTTP systems are great for this approach, but you can apply it to others as well.

Starting point with the old system behind a load balancer.

Add the facade to the loadbalancer. This provides a good way to validate the facades operation without risking 100% of your traffic. It also gives you a great opportunity to improve your monitoring and gathering of statistics.

Once you are confident in your facade, remove the old system from the loadbalancer and now you have all traffic through the facade.

Now you are in a position to start adding new functionality and potentially replace functionality from the old system in the facade. This phase can take a long time as incremental changes are made. You are effectively fading out the old system.

As all the old functionality that is still used is now implemented in the new system, the old system is now redundant and can be removed.

Architecture never stands still, it is never static, you need to understand that it is under constant change. Techniques that enable you to smoothly evolve your architecture safely will give you a great competitive advantage.

All too often we conflate the unfamiliar with the complex. Whenever we don’t understand something we immediately reach for the ‘this is complex’ label. After all we are smart people right?

However, what we really mean is: this is not in my sphere of experience or cannot easily be extrapolated from that experience. It is not familiar.

Language X is complex, tool Y is complex, technology Z is way too complex.

We don’t like to admit we don’t understand something. We really do not like uncertainty, to the point we will lie even to ourselves.

I sometimes catch myself thinking “this is complex” - and have to step back and think, why do I think it’s complex? Is it really complex or am I just missing some vital context, some background, am I just unfamiliar with the terminology.

Sure there are plenty of things that are complex. After all it is easy to build something complex, it’s extremely hard to build something simple. I admire greatly those individuals and companies that have the skill, patience and diligence to build truly simple things.

So when you are faced with something that you feel is complex, step back and think is it? Or am I just feeling that dreaded sense of unfamiliarity.

Few projects make an effort to make newcomers familiar with the context, the background and the approach - something worth considering in your next project, and if it is hard, perhaps what you have built is complex.

On this subject Rich Hickney has a great talk about simple vs easy. It’s worth a watch, I’d recommend not getting hung up on examples, after all they come from his realm of familiarity but listen to his arguments.

I had the pleasure this evening to speak to the London Scala Group, at the very nice bar in the ITV London Studios.

The talk was around the experience we’d had in using Scala for 2 and a half years, with 2 years in production. Unfortunately it wasn’t recorded, so if I can find the time I will turn it into a blog post - hopefully on a zeebox engineering blog.