Craig Pardey

Thurs Mar 26 2026 was a significant milestone on my quest to liberate my team from the tyranny of my client’s enterprise deployment pipeline: we successfully deployed a service to production using my Shadow Pipeline (see my previous posts: here and here).

Background: My client’s enterprise deployment pipeline is slow, clunky, and unreliable. Deployments take at least an hour per service per datacenter and often fail. When it fails we have to open a support ticket and page the pipeline staff to fix it which often takes hours. My client only permits overnight deployments to production starting at midnight, and smooth deployments usually run until 5:30am.

[Read More]

My client is looking to hire senior backend developers with good written and verbal communication skills that can be in the office 2-3 days per week.

They’re also undergoing a “strategic workforce reshaping with global delivery partners” which means they’re hiring low-cost developers from the large outsourcing companies: Cognizant, CGI, Accenture, and Tata. I’m not privvy to the agreements that are struck with these vendors but I can speak to the strain this strategy puts on engineering teams. We’ve screened and interviewed dozens of candidates and haven’t made a single hire.

TL;DR My client is paying top dollar for enterprise licenses for a platform that their own policies prevent people from using.

My enterprise client has a few open roles for developers so we’ve been asked to interview candidates. After the first batch of resumes we decided that we needed to do some pre-screening because the agencies certainly were not.

I reached out to the client’s recruiting department to ask about getting access to a technical screening platform like CoderPad, Codility, or HackerRank.

In my recent post about CI/CD performance, I mentioned that I’d built a shadow pipeline in Ansible to deploy to our on-prem dev environment. Since then, I have been campaigning to use those Ansible playbooks for our pre-Prod and Prod deployments too.

I secured approvals to do a proof-of-concept deployment to pre-Prod using the Ansible playbooks but it failed dismally because our pre-Prod VMs have drastically different sudo restrictions than our dev env. I do not have access to the pre-Prod VMs so I was not aware of these differences.

My current client has an enterprise CI/CD pipeline that is maintained by a centralized team that does not use it. Its product owner(s) do not rely on its output for their revenue. They are not measured on its performance or reliability.

And yet we are obligated to use this pipeline. There’s no other option. We were also handed a microservices architecture from the Architecture team so our application is comprised of about 20 separate services, each with their own deployment pipeline, thereby magifying our sensitivity to the whims of the enterprise CI/CD pipeline.

Payments Canada published an opinion piece outlining how they think ISO fits into the payments ecosystem.

The ISO 20022 standard provides a common language for Financial Institutions to use when communicating with each other. It brings consistency and well-considered data structures to interfaces that previously had none.

ISO 20022 defines a catalog of messages to standardize data exchange in the finance industry, and it is gaining popularity in Payments.

Here in Canada, Interac updated their APIs to support ISO 20022 several years ago. FedWire in the US will be rolling out ISO 20022 support in summer 2025, and Zelle is following suit with its integration to The Clearing House’s Real-Time Payments network.

But it’s not a standard despite what the name implies.

I wrote about DRY configs many years ago but astonishingly my clients don’t seem to read my blog. I mean, who even has a blog these days anyway?

Externalized application configs have a way of multiplying like rabbits to the point where people become afraid to touch them at all, let alone apply the DRY principle to them. The proliferation of poorly-designed configuration files in Enterprise Java systems is appalling, and the situation is compounded when an external configuration system like Consul or Spring Cloud Config is added to the mix.

I recently had to return an item that I’d bought online. It’s free to return the item in-person to one of their retail locations, or $10 to ship it back. There was a store nearby so I elected to do an in-person return but the experience shows what can happen when software and processes are developed without involving the user.

The store clerk was friendly and helpful. He asked for my online order number, found it in the system, and told me that the money would be refunded to the original form of payment used for the purchase - in this case, PayPal. Everything is going smoothly to this point.

Only by increasing flow through the constraint can overall throughput be increased – Eliyahu M. Goldratt, The Goal, 1984

Turning this around we get the corollory that optimizations made to areas other than the constraint only serve to worsen the constraint.

Agile practices, and particularly Scrum and SAFe, have been widely adopted in large enterprises over the last decade or so, spawning entirely new departments dedicated to locking down the process. Agile Centers of Excellence (CoEs) produce materials explicitly describing every aspect of their company’s specific flavour of Agile, and have coaches dedicated to enforcing it across the teams.