Published: What is Continuous Delivery?

Over the years, I have interviewed and observed a decent number of technology organisations. Many shared that they have Continuous Delivery in place. But, only a few really practised Continuous Delivery. There is a lot of misunderstanding about what Continuous Delivery actually is and what it entails.

It takes nine principles, one heuristic, three foundations, one pattern and three practices to practice truly Continuous Delivery.

https://thinkinglabs.io/articles/2026/01/09/what-is-continuous-delivery.html

Most relevant IT books 2025, IMHO:
📕 "Architecture for Flow" by @suksr
📗 "User Needs Mapping" by Rich Allen
📘 "Frictionless" by Nicole Forsgren and Abi Noda
📙 "Code Health Guardian" by Artie Shevchenko

All of these books address collaboration and shared understanding from different perspectives and on different levels.

Quite a challenge again to select only four books – thank you for sharing your experience in printed words 🙏

I finally decided to write to make me feel like my quivering existence isn't merely job search anxiety. So what started as a simple book review sorta took on a life of its own!

Since @adrianco turned me on to Architecture for Flow by @suksr, I have been simmering with thoughts about it. I finished it last month and it has shaped what I've answered during interview questions.

But not only that, Susanne has created a great stepping-off point for me to talk about how to treat Incident Management in the context of achieving Architecture for Flow:

https://www.sounding.com/2025/11/06/flow-for-incidents/

#SRE #Incidents #Observability #WardleyMaps #TeamTopologies #DomainDrivenDesign #ArchitectureForFlow

Minor medical situation on the flight and it’s cool that my wife is able to jump up and help out when they ask for a licensed medical professional.

One day someone will need a regular expression so I stay ready.

I’m always saying that with Event-Driven Architectures, the modelling effort pays back. That goes both ways: the less effort we put in modelling, the more it’ll hurt later.

There’s a wide range of issues you may be facing, from overfocusing on the state instead of tracking behaviour, to asking others more often than allowing them to tell you what happened, and ending with race conditions and other unpleasant scenarios.

I packed as many of such cases into our talk, and the recording from this year’s @dddeu just arrived: https://www.youtube.com/watch?v=Lf1MZlpbkGA

During the session, I explained the specifics of event modelling (yes, no capital letter, and double l), starting with bad practices and knowing why and how to avoid them.

I told the story about the project that aimed to modernise legacy software into the event-driven world. In theory, artificial, but in practice, none of the examples were made up. Either I made those mistakes on my own, or I saw them in my projects or helped to fix them for my clients.

I tried to make it both entertaining and educational, bitter and sweet. It is not easy when you’re not a native speaker. There’s a thin line between being funny and being silly.

There’s also a thin line between bad and good practices. And its name is: context.

Also, as much some of those cases may seem wild, I can assure you that all of those mistakes I either:
- did by myself,
- saw in my projects,
- saw in my client’s project.

Check it out, why learn always from your mistakes?

Learn from mine.

Last week, I received a box full of the new printed book "Architecture for Flow" by @suksr

I hoped Susanne would receive hers before I posted, but you need to know it's available:

Order from InformIT(.com) now and from Amazon with 1-2 day delay, which is likely because it's selling like hotcakes:

#8 in Software Design & Engineering
⭐️⭐️⭐️⭐️⭐️

Order yours today!