We all want to build better software faster and more reliably. Many valuable simple improvements in code practice, design and process are easy to spot from outside the team or organisation but it is always challenging to know what the best thing to work on is day-to-day.
External impetuses from consultants, managers, consultant reports or even customers are not always valuable to the delivery process. Why? Because we are told that we want to achieve a pipeline of our activities. We wish to envisage new feature requests and bug fixes flowing through our pipeline effortlessly from start to finish. Flow theory tells us that we are, either individually or as a team, at peak performance when we are in 'flow'. The pipeline model helps us reinforce this idea of flow in our conceptualised work. This makes us feel comfortable. We come up with ideas, we prioritise ideas and the ideas, bugs or features are incorporated into the software, and we deliver the perfect result.
But, of course, we know software is rarely perfect. There are distractions, interruptions and changes outside of our control. Therefore, should we model our workflow as a pipeline at all? If we accept that software is not ever going to be perfect - then why should we envisage it as a pipeline at all? Isn't that the wrong visualisation? Haven't we been getting it wrong all of this time?
For me, Barry M. O'Reilly's work is closer to the mark with his philosophical stance on software residues. Residuality Theory assumes that software will always fail but some parts will remain. Those remains or residues will have already been proven to be stronger than the rest. Intrinsically, Residuality Theory expects and predicts the eventual failure of a software system. If we, therefore, expect software to fail, then our whole concept of a smooth delivery of software is surely false? The delivered artifact is already imperfect because we know it's going to fail at some point. Therefore, why should we treat elements of software delivery as smooth, perfect pipelines of work? Why should we expect it to act as a pipeline at all?
I recently saw a paper which attempted to show how a high workload on project teams could cause turbulence in the 'flow' of work items through to completion. While I applaud the paper and how it attempts to show how high Work In Progress is a bad idea for teams - it assumes that features flow through a delivery system. I believe that features don't flow through a delivery system. Instead features, bugs, ideas, customer feedback are all just inputs to a system which is constantly in flux. Our software is ready to fail but we just don't know it yet.
Ok, so if we assume what I say is true - then what's the point of building more software if it's doomed to fail?! This sounds like a rather gloomy, nihilistic assessment of the state of software delivery.
Well, I believe that it's just a case of not letting ourselves get trapped into thinking about software as a bunch of pipelines that work effortlessly. Let us instead consider that our pipelines are just collections of systems which are working independently to help our delivery rather than providing the mechanism for delivery itself. What does this mean?
Let's look at the pipelines we might typically use in software delivery:
These all help us understand the work we have to do, and do it more reliablity and more quickly. So far so good. But if we accept that the delivered software is going to have faults, then what pipeline are we missing from this picture? I suggest we're missing a feedback pipeline:
So, what is the best advice to improve your software delivery right now? Stop thinking that software delivery is a single pipeline of work, start thinking about how you can improve the individual pipelines in your delivery, and also think about and prioritise a method of creating a 'feedback pipeline' to receive and act on system feedback before failure.
I'm sure I'm not the only person to have said this but would love to hear your views on this approach to pipelines and prioritising feedback.
---
I'm hosting the first ever 'Fast Flow' meetup in Amsterdam (and whole of NL) next week. You can join here and we're hoping to make a recording of the event available shortly afterwards. More details can be found on the meetup page.
---
I'll be talking about platform engineering at the next DevOoops Meetup in Amsterdam on the 22nd November.
--
Finally, to round out my investigations into productivity, I came across this post about ADHD and Toxic Productivity from Jesse J Anderson. Has some interesting insights, not least about how planning and the ADHD brain go together.
--
Until next time, have a great weekend!
Best,
-- Richard
Published on October 31, 2023
I recently wrote about Avoiding Toxicity when it comes to developer productivity. I’ve also been doing some research into ADHD following a recent diagnosis in the family and therefore, I was interested to stumble across a video from Jesse Anderson, which explains how toxic productivity can arise from having ADHD. He also opens with the… Read More »ADHD and Avoiding Toxic Productivity with Jesse Anderson
DevOps at is the heart of modern software systems. In my regular newsletter, I dive into the human factors that make successful engineering organizations where teams and platforms thrive at the heart of your socio-technical systems. From leadership to team setup, maximizing performance, tools and techniques.
September took me to London to attend a couple of conferences. The first was the Team Topologies-aligned Fast Flow conference , preceded by a workshop with the Team Topologies core team. I also popped into the Design Museum when I was in the area, an inspirational space if you're ever in London. The Design Museum in Kensington, London. As part of the work I do, I sometimes bump into like-minded folks. While I didn't catch up with them at Fast Flow Conf, a few days ago I enjoyed chatting with...
How was your summer? Does it feel like it's still happening, or are you already back in the thick of things? It's been a bit of both for me over the last few weeks. I've been in and out of holiday mode. The weather is still hot, but the office is in action. Next week, I'm off to London, where I'll be attending the second edition of the Fast Flow Conference with the Team Topologies organisation and heading to SaaS CTO Conference to meet with tech leaders and find out what's got them worried...
“Through the years, I have learned there is no harm in charging oneself up with delusions between moments of valid inspiration... Thankfully, persistence is a great substitute for talent.” – Steve Martin, Born Standing Up: A Comic's Life You're receiving this because you subscribed to receive updates about "Human Software" or you're on my Human DevOps mailing list. The summer season is upon us. Originally I was aiming to have some early chapters of my debut novel "Human Software" available to...