Sisyphus and Continuous Delivery

Like Sisyphus, damned to push an enormous boulder up a hill each day only to watch it roll back down, those of us in the Technology industry are compelled with a similar burden in the way we used to manage software, in the world of monolithic/waterfall software delivery — and this can include even those using Agile processes.

We relate to the exhaustion that Sisyphus must feel while looking down the hill — which in our case is a release or change to our software. This should be a moment of triumph, but instead it lasts about as long as it takes for the next change request, or the vendor to release a new update, and the boulder crashes back to the bottom of the hill.

The situation worsens, because not only do we have to maintain the software we care about — pushing that boulder up the hill for eternity — along with each change we have testing, verification, client assurance, compliance checks, audits, and eldritch security requirements that nobody quite knows why we need to follow — other than a sysadmin in the dark room down the hallway, but that is a separate conversation about DevOps.

Additionally, as you have this long "waterfall" boulder release cycle that may take weeks — if you are lucky — or months for many people, what happens if you need to make a bug fix? Have you ever faced any of the following challenges with your own releases?

• If somebody finishes a part of the work before the larger body is ready to go, how do you push just it? — and if you do, how do you merge it back into the other code? Branches? Forks?
• Can you push out something before the main release is ready?
• What if you have two or three different changes happening in parallel?
• How does it all get tested? Do you test the entire system, or just the part that changed?
• Are you properly meeting security requirements, auditing and reviewing your operational procedures?

All of these, and more, are what creates the overbearing burden of waterfall / boulder style releases. Each of these added burdens requires you do more with less. Your staff cannot keep up.

Maintaining software in the modern world is an exhausting saga equal to any of the horrors of Greek mythology.

But it doesn't have to be.

When you move into the world of Agile, you start to think about changes as smaller increments, because that is how your organize your work.

If your work is small enough, you can break the large boulder into small pebbles that are moved up the hill constantly by individuals, rather than pushed as a gigantic boulder by the entire team. This is Continuous Delivery — focus on making automated and small changes in a continuous flow that is tested through a pipeline into production.

In this world, if a pebble drops because of a bad push, it doesn't crush the team as it rolls to the base of the hill. Instead, the developer picks it up, brushes off the leaves and twigs, and continues up the hill.

And this, at the end of the day, is why Continuous Software releases make for a better, more robust system; and why everybody who really "gets" it becomes so breathless when talking about it. Not only is the impact of mistakes greatly reduced, smaller changes means more frequent updates, which means the update process is streamlined, meaning you get a feedback loop of improvement on all these things, rather than the opposite.

The entire software engineering cycle improves.