Skip to main content


Quality and Pragmatism

Pragmatism and quality are two things that are often pitted against each other when delivering software. When I think of pragmatism, I think what things can be avoided in order to deliver software to our customer sooner. When I think quality, I think a whole range of things including: maintainability, scalability, and interoperability of a system to name a few. It may also mean things that may not directly relate to the system for example: documentation, support, and user customisation.

At times we need to strike a balance between quality and delivery. This is called pragmatism. The art of striking this balance is difficult. Each software engineer’s experience is different, many engineers have been burnt by similar things. Some have been burnt by different things. As a team, it’s hard to be pragmatic because of these varying experiences.
Recent posts

Do you know what I mean?

I've written previously about some language that I'm actively trying to change in my day-to-day dealings with people, I write these blog posts because they hold me public accountable to my peers, friends, and family. My previous posts were:

It Depends
I Don't Know

Reboot DevOps (Part: III)

As alluded to in Part 1 and II it seems that DevOps has just become about CI/CD pipelines, provisioning infrastructure, and deploying applications. Today, we'll speak about CI/CD pipelines but more specifically the purpose they seek to provide.

Firstly, I think the term CI/CD is counter-intuitive. It's not a descriptive term and I would prefer to use the far more boring term release pipeline because it is self descriptive. Our primary concern is how does candidate code get from a local developer's machine all the way into production. Here we need to employ ToC (Theory of Constraints) thinking to really understand the reasoning of CI/CD in the first place.

the level of utilization of a non-bottleneck is not determined by its own potential, but by some other constraint in the system. - Dr Eli Goldratt

Reboot DevOps (Part: II)

In the Part I we discussed how DevOps isn't about solving application problems using infrastructure but about being able to deploy to our targets in a sustainable way. We spoke about how increasing confidence enables personnel to release more often as risks are hedged by having solid application packages.

Today we will speak about how monitoring and observability can increase our confidence to enable us to release more often.

Reboot DevOps

In an ideal scenario a large organisation would have DevOps capabilities spread across their various teams. There would be no need to lean on an operations team to do any deployment, scaling, or observing of applications. Engineers would understand the inside and outside of infrastructure, security, logging, and message brokering.

The world isn't ideal though, that's not an excuse not to strive for the ideal.

This blog post will be the first on a series of posts examining my thoughts on the current state of DevOps and what I think we can do to improve.

Standing in a Circle Clapping is Not Agile

For many organisations going through an agile or digital transformation, there seems to be a culture of standing around clapping. When this behaviour is regular and habitual for every little achievement, I become sceptical of its value.

Today, I would like to explain to you my scepticism.

It depends

A few months ago I wrote a post I Don’t Know. It was a post that explained why being honest about things you don’t know is important, as it builds trust amongst team members. I also explained why saying you don’t know something and following it up with a desire to actually take action, in order to gain that knowledge, is important. Today, I will talk about the words “it depends”.

Consultants are accused of overusing this phrase and rightly so. You see, if someone is asked a question and the response is “it depends”. Neither is the question answered nor is the information necessary to answer the question supplied, or a request for more information communicated.