Continuous Delivery

Recently, I’m hearing a lot about continuous delivery, and even continuous deployment. Both are fantastic, and I’ve seen many places reap the benefits of such models.

Continuous delivery is when the practices used by the team enable the software to be reliably released at anytime. Every change has the confidence to go straight out to production.

Continuous Deployment is the next step, where the software is not only ready to be released, but is released out to users. Every commit out to production.

I see software which is released less often, because it is risky, and often, a scary proposition. The objective of both practices is to make deployment a “non-issue”.

If it hurts, do it more often

Left out of the conversations is the value it provides. Not from a technical perspective, but from the business. After all, that is the reason we do anything. For provide value / benefit to the business.

Our objective is to minimise our time to market, which is a another topic in its own right due to the many factors that impact that metric.

We need to ensure our software development keeps its agility, and enables quickly responding to feedback.

The main reason why these models are so beneficial is because packaging, regression testing, deploying, waiting and so on, are non-value adding activities. These activities can be mundane, tedious, and should be automated if possible.

Business should not be waiting for Technology, Technology should be waiting for the Business.

As we all strive for that goal, these two models take great strides in getting closer to the mark.

If we find resistance for these two approaches, you will most likely be dealing with software which has lost its agility, or struggling for quality, and we all know what happens in that case…

How important is UX?

User Experience has been gaining momentum and importance within companies, but have leaders really connected with what it means?

It is hard to argue, that user experience is paramount, in engaging and retaining users / customers. I’m sure most would agree that it is simply common sense.

But we are still in an age where good UX can be a market differentiator. How many companies are driving UX as a high priority?

Even more importantly, which companies have its leaders (C – Level, ie – CEO) pushing for, and driving UX?

Companies need to stop focusing on revenue, and thinking about UX. Revenue is a by-product of UX.

When we think about the metrics that top level management focus on, I assure you revenue would be very high on the list, if not top. Rightly so, but perhaps a shift in thinking, to focus on building raving fans (aka UX), will enable the revenue growth simply as a by-product, and perhaps a few other metrics such as staff satisfaction and engagement.

Food for thought…


Elastic Beanstalk is evil!

For all you AWS’ers out there, I’m hoping this will provide a reason to avoid the EB (Elastic Beanstalk) stack. A quick summary of “what is elastic beanstalk” from Stack Overflow:

Elastic Beanstalk is one layer of abstraction away from the EC2 layer. Elastic Beanstalk will setup an “environment” for you that can contain a number of EC2 instances, an optional database, as well as a few other AWS components such as a Elastic Load Balancer, Auto-Scaling Group, Security Group. Then Elastic Beanstalk will manage these items for you whenever you want to update your software running in AWS. Elastic Beanstalk doesn’t add any cost on top of these resources that it creates for you. If you have 10 hours of EC2 usage, then all you pay is 10 compute hours.

So I’ve recently finished delivering two projects using Elastic Beanstalk, and initially I was a fan. It brings everything into one dashboard / centralised control area. Your Load Balancers (ELB), Autoscaling groups (ASG), EC2, Notifications, Monitoring, Metrics and general Orchestration.

It provides a way to get zero downtime deployments, using two stacks and performing CNAME swaps (Blue / Green deployments).

Rather than creating two seperate stacks for each environment, we decided to go with rolling updates as our “zero downtime deployment” (I am not going into the details of how we achieved this – email me if you are interested and I’ll be happy to post).

This worked really well for the first few months… until we used it in anger within production. Now, if elastic beanstalk fails to deploy, it retries 2 times (total of 3) and then starts to roll back.

It will then attempt to roll back. It tries to roll back by deploying the original version on new servers. If that fails, it will try 2 more times (total of 3). If that fails as well, the EB stack goes into a grey state. I call it zombie state.

Lets not go into why this could happen (because there are many reasons why, ie – bad health checks).

Regardless of your underlying resources, your EB stack is deadlocked. You cannot recover it AT ALL.

Even if your  underlying infrastructure is fine, the web server or API is working and serving users – EB will not accept any changes, new deployments, changes in configuration until you tear down the physical resources, and rebuild.

Essentially the abstraction layer on top of these services has deadlocked and it cannot be fixed.

As soon as you tear down your EB stack, there goes your IP, and welcome DNS caching issues.

My recommendation for anyone building serious production services – avoid the EB stack. Even though it seems great at the start, it will cause you pain as time wears on.

The pragmatic craftsman

I’ve been working in software development for a solid 15 years now, and I’ve seen all sorts of projects, and developers.

While software craftsmanship is talked about a lot, and quite often seen in job ads; one thing often left out is pragmatism. In fact, I’ve seen software craftsmanship taken so far, that it has killed projects, and products.

This is not a post to say craftsmanship is bad, I am the first to admit writing good, clean code is very important for the long term survival of a product. There is value in good, clean code without a doubt. Unfortunately, I see it very often, developers over think a solution, or try to flex their “technical muscles”. What results is an over-engineered, or overly complicated solution.

Pragmatic – Dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations

Stepping back a bit – Our job is to solve problems, in a cost effective manner.

Not to use the latest technology, or patterns to build your CV. It isn’t to use CQRS, Event Sourcing or Docker because it is cool. And not to mention over designing, products for every edge-case up front.

No one can design the perfect solution up front. An idea I always try to drive through teams I work with, that has served me well – deliver quickly, and leave time to iterate.

A question I always ask during design reviews is – “Do you need it?”. At times it could be a pattern I am questioning, a framework, or technology. I’ve even done it to automated tests.

If the team cannot outline value a choice is going to provide, it shines light on it very quickly. It isn’t to push back, or cut anyone down – sometimes I use the question to ensure the team understands why a choice was made. As we all know – there are no silver bullets.

And a reminder – Tests aren’t the only thing that will sustain the software over the years, it is simplicity. Many developers will work on the code base, and our job is to make it easy to understand, and safe to modify.

The “pragmatic craftsman” as I call it, is one that not only builds well crafted software, but focuses and delivers business value iteratively. They cultivate raving fans, should be egoless, humble and most of all, focus on the outcome.

I enjoy working with talent developers, but I love working with pragmatic craftsman.

Hello again world

As my first post on this new blog, I wanted to write a big thanks to two people who have given me the nudge to start this blogging again.

The first one is Tal Rotbart. I’ve worked with Tal for close to 18 months now at PageUp, and I’ve got the say, I have learnt a great deal from him in such short space of time. He is a very strategic thinker, and quite a different mould of “techie”. One of the most talented guys I have worked with.

He encouraged me to focus on building a public profile, and share my thoughts. So… here I am, back to blogging.

We are currently on a very interesting journey, realigning a product company, as well as the classic journey from Monolith to Microservices. I have grown a lot, and learnt a great deal of things in the past 18 months, so this is the start of sharing some of those learnings.

The second one is John Sonmez. I’m sure John has influenced quite a number of developers, but I’ve been following John’s work for a number of months now and he has an interesting way of connecting. His free course on blogging is what got me going, and to be honest, it is a little more fun with the structured approach he has provided.

I’ve been in touch with John through this free course and it is nice to have the personal touch – not just an automated email system.

So cheers to both of you!

%d bloggers like this: