Skip to main content


Showing posts from 2018

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.

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.

Stop Demonising Process

All too often people appeal to being "Agile" as a way to avoid following or having process. It could be because the term "Agile" implies flexibility or even because the Agile Manifesto itself says explicitly that "Individuals and interactions over processes and tools". Here, the manifesto doesn't say that being "Agile" doesn't mean you don't have process, it simply says you favour individuals over process. The demonisation of process could also be a knee jerk reaction of when teams had process imposed on them.

How rock climbing, cooking, and weight lifting help us relate to software delivery.

Incremental, iterative, sprints. Whatever word you may use, the whole point is, as the agile manifesto says to Deliver working software frequently. The key here is working not necessarily perfectUsing the words just mentioned or even the word agile can cause some confusion. One of the most common aspects of confusion for people not wanting to deliver incrementally and pushing a large amount of changes into a future release is Aren't we agile, let's be flexible. Of course, this perception of flexibility ends up hurting the team in the future because many changes are pushed through one big release. What this means is if something goes wrong we're simply guessing which change caused the bug.

Here are a few analogies I've been working with to help people understand the importance of frequent delivery.

Scaling Agile with GRC (Governance, Risk, and Compliance)

In the 21st Century, software is at the forefront of our lives. Our insurance, money, communication is all done via software. As such, the importance of GRC is becoming ever more apparent as more and more sensitive information is being stored and viewed by a range of people. We as software practitioners have the responsibility to ensure we store data securely, encrypt communication, output data in a legal and compliant format, and make everything accessible to the general public. At the same time we want to be able to make changes to our platforms as quickly as possible to interact with market conditions.

GRC has always been something of an awkward conversation when it comes to agile delivery. There's no questioning the value of end-to-end delivery that includes the delivery of GRC related activities such as: security, accessibility, and financial reporting. GRC should be a function of delivery, not an afterthought. At the same time, the value in having independent auditing in are…

Book Review: Leading by Alex Ferguson

Alex Ferguson was Manchester United FC's manager for 27 years. During this time he managed the club to multiple titles while leading some of the most hard working, talented, and high performant players on the planet. I thought I'd give this book a shot to see what I can get out of it in my everyday life. Whether you like Alex (Or Manchester United FC) or not. It is clear that Alex was successful in his tenure at United and Aberdeen.What aspects of Alex's experience will I take into my software delivery life? And what aspects I won't?

Commerce, coffee, and value

According to Wikipedia, commerce is the exchange of goods and services that existed as part of the human story since prehistoric times. Before currency we used to barter, then we began to use currency backed by resources like gold, and now we use fiat money (currency backed by the issuing government).

As humans we've learnt that this is the way we exchange value. When I go to a particular coffee shop on a Saturday it's because I judge that the value in the coffee given to me is better than the shop next door. I may even be willing to pay a little extra depending on the value provided. In this case, the value is the extent to which my taste buds are excited from the coffee.

Tips to Automate Yourself Out of a Job

Providing tools, processes, and platforms that automate everything, including yourself out of a job should be the goal of everyone in IT. It's something people rant about on Twitter, speak about on YouTube, and attempt to inspire on LinkedIn. Everyone seems to be telling us we should automate our jobs, not many are telling us how. Today I have a few practical things you can do to actualise this goal.

Book Review: How We Got to Now by Steve Johnson

How We Got to Now is a book that I can't really put into any individual genre. It isn't a novel, isn't a collection of small stories, isn't purely educational, and isn't historical. It is a combination of all of these genres and that's what makes this book unique and enjoyable.

The book How We Got to Now describes, as suggested by its subtitle, "Six Innovations That Made the Modern World". In the introduction Steven Johnson describes evolution and the way one change can trigger a change throughout the course of all of evolution. He also explains various other casualty phenomena to create an overarching point of linkage throughout the whole book. The most notable of these examples is the butterfly effect.

Build and Release Pipeline for Your Own Custom VSTS Tasks

Anyone can create their own custom VSTS tasks and put them on the VSTS marketplace. There are tons of these custom tasks and they can be published publicly into the marketplace or privately into your own instance of VSTS. This blog post will demonstrate how to setup a build and release pipeline for these custom tasks (using custom VSTS tasks!).

There are many reasons to create your own tasks on an instance of VSTS. You could be part of a DevOps capability that wants to share common platforms, standardisation, or integrations. Generally though the reasoning is to avoid common steps that are duplicated across different build and release pipelines.

Using SBAR in code reviews

After the end of a messy sprint everyone was excited and scared to attend the sprint retro. The topic we were dreading the most came up - pull requests. It had been a sprint where few pull requests went through smoothly and everyone was picking up issues with every pull request. Stylistic things came up, whole features needed to be redeveloped, people were clearly annoyed, and you could sense the tension in the room.

Then, a suggestion by our non-technical product owner (who was a nurse and who had never been a product owner before) Why don't you use something like the SBAR technique?

Transformation, reorganisation, and continuous improvement

It seems that almost everywhere I look, a big corporate is going through a 'transformation' or 'reorganisation'. Clearly someone within these organisation is making the decision that this is required because of problems occurring with existing software delivery practices.  That is, they want something improved.

Throughout 2016, I lost more than 20kgs of weight. I did this very slowly through dieting and returning back to my previous exercising habits. I've maintained this weight throughout 2017 and now. How I did I do this? Well, I took out the obvious cheap calories out first: sugary drinks and junk food. When the weight started slowing I then took out desert. When the weight started slowing again, I reduced my carb intake. When it started slowing again I cut out carbs. When it started slowing again, I began to count calories. I now have kept the weight off, feel reat, and habitually live a healthy lifestyle. I am also able to indulge every now and then. NB: I'…

Book Review of 'TED TALKS' and what I learnt

For those of us wanting to improve our public speaking, have been speaking for a while, or just starting out. This is a great book which was lent to me by my colleague Paul. Below is my review which covers 'how I read it', 'what were the main points', and 'what was missing'.

'Hierarchy' the dirty word

Modern human resource departments dread the word "hierarchy", companies happily boast of their "flat structure" in job advertisements, and national leaders are disparaged as being out of touch. However, when is a bit of hierarchy actually good? When is it worth it?

My personal issue isn't with hierarchy. It's with excess, unneeded hierarchy. Hierarchy can be good as it means the higher up the individual goes, the more responsibility they have. Problems arise in organisations where individuals in higher levels of a hierarchy do not have much responsibility and thus do not do much work.

Make your code review requests count

The value in PRs (or code reviews in general) is more than just ensuring good code is pushed into the main-line branch. There's more to a PR in my opinion. This includes

•Learning from others
•Sharing learning, understanding, and the architecture of your system

3, 2, 1 - REVEAL POINTS. The true value of poker sizing

Many of us are in teams with a good habit of sizing work items, and in many cases this is a good habit. However, do we truly understand the importance of this behaviour? Why do we do it? Is it even necessary, and where is the real value of all this?

My top 3 development tools

Every developer has a set of development tools which they use on a regular basis. Below is a list of my top three tools, why I use them, and how they benefit me. In the list below I haven't included code editors, IDEs, or extensions to IDEs. Please note: this may disappoint many of you who are expecting something "advanced" or "funky".

Git breaking? Get off the UI

Git is perhaps the best VCS I've used in my life. However, some of the things I always hear when people are trying to learn Git, or have used it for a while but never in larger teams are:
"something stuffed up my Git"
"my Git is broken"

In my experience, Git is probably the most predictable, deterministic tool I've ever used (thankfully, considering it does version your code!).

I Don't Know

Many people who come from command and control working environments have a very limited circle of safety. This maybe because their suggestions have been discarded rudely, being treated poorly, or always fearing for their job. They do not suggest improvements and are often too scared to ask for help.