Recently I tweeted that “Interesting things happen as deployment costs approach zero”. From that I got a few questions about what I meant and why that may be.

Firstly a distinction, I said deployment and not release. They are different things. A release requires a deployment in order to deliver a feature or bundle of features that are needed in a particular environment. But a deployment may infact be the existing artifacts or a set of previous artifacts (for example a roll-back).

What do I mean by the cost of a deployment? I am not talking so much in monetary terms, but more in the energy expended by the members of your team. How mentally challenging is a deployment, does it:

  • envoke a sense of fear?
  • require a lot of box ticking?
  • result in a scramble to get signatures and approvals?
  • need hours of planning and scheduling?
  • require a lot of typing?

A deployment should not result in any of those things. Deployments often do however and it typically boils down to fear. Fear of making mistakes because it is hard.

The problem with fear of deployment is that it becomes self reinforcing, because we are afraid, because it is hard, we make mistakes which in turn makes us more afraid, which makes us hesitant to do it again and makes it likely for us to add even more sign-offs to make it more difficult to make mistakes next time.

Who has worked anywhere where a release has gone wrong and all of a sudden all releases need to be approved by the CTO/VP/Director or even CEO? Most of us I am betting. Now what happens when that doesn’t actually happen, but rather the process of deployments is made, simple, safe and transparent? This is what I mean by cost approaching zero.

We have observed the following:

  • More deployments happen, as there is little penalty incurred.
  • The difference between active developer code base and the code base actually running in production drops.
  • Time is saved as engineers spend less time considering and debating if a deployment is worth doing. (Or complaining about the deployment process).
  • The decision point as to whether as a deployment can be done or not moves from Senior Management down to the group, then down to the team lead and ultimately down to the engineers working on the changes themselves. (This does enormous things for team morale and feelings of empowerment).

You find that as the confidence increases that all of a sudden a deployment for a one line change (and a proper one, not a hack) becomes possible and actually begins to happen. This opens the door for faster iterations, it enables more experiments and for the developers themselves to begin driving incremental improvements such as taking on refactorings that otherwise might not happen.

All of these things add up to a better product, a less fragile product and happier teams.

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.