DDD Europe 2022 Watch-List

I attend conferences and open spaces for more than 15 years but I can’t remember ever being keener to go to a conference than the DDD EU this year. But I still haven’t imagined that my list for “watch later”-videos will be almost as long as the number of talks – including the ones from the DDD Foundations (2 pre-conference days).

I was so full of expectations because I would be a speaker at an international conference for the first time and the opportunity to meet all those wonderful people who became friends in the last two years! (I won’t even try to list the names because I would surely miss a few). The most often repeated sentence on those five days wasn’t “Can you see my screen?” anymore but “Do you know that we never met before IRL?!” 🤗

This was only one of those great evenings meeting old friends and making new ones 🙂 (After two years of collaboration, the Virtual DDD organizers have finally met too!)

But now back to the lists:

Talks I haven’t seen but I should:

  1. DDD Foundations with clever people and interesting talks which should/could land in our ddd-crew repositories. (In general, the sessions are not too long, I will probably browse through all of them.)
  2. Main Conference

Talks to revisit

This list is not the list of “good talks”; I can’t remember being at any talk I wished I wouldn’t. But these here need to be seen and listened to more than once (at least I do).

Domain-Driven Design in ProductLand – Alberto Brandolini

Alberto speaking the truth about product development is exactly my kind of radical candour.

Independent Service Heuristics: a rapid, business-friendly approach to flow-oriented boundaries – Matthew Skelton and Nick Tune

The tweet tells it all: an essential new method in our toolbox

The Fractal Geometry of Software Design – Vladik Khononov

Mindblowing. I will probably have to re-watch this video a couple of times until I get my brain around all of the facets Valdik touches in his talk.

Sociotechnical Systems Design for the “Digital Coal Mines” – Trond Hjorteland

This talk is not something I haven’t understood – I understand it completely. I will still re-watch it because it contains historical and actual arguments and requirements for employers on how they have to re-think their organizational models.

This is the longest list of videos I have ever bookmarked (and published as a suggestion for you all). Still, it is how it is: the DDD-Eu 2022 was, in my opinion, the most mature conference I ever participated.

At the same time, there is always time for jokes when Mathias Verraes and Nick Tune are around (and we are around them, of course) 😃

What Does Continuous Delivery to a Team

Tl;dr: Continuous integration and delivery are not about a pipeline, it is about trust, psychological safety, a common goal and real teamwork.

What is needed for CI/CD – and how to achieve those?

  • No feature branches but trunk-based development and feature toggles: feature branches mean discontinuous development. CI/CD works with only one temporary branch: the local copy on your machine getting integrated at the moment you want to push. “No feature branches” also means pushing your changes at least once a day.
  • A feeling of safety to commit and push your code: trust in yourself and trust in your environment to help you if you fall – or steady you to not fall at all.
  • Quality gates to keep the customer safe
  • Observing and reducing the outcome of your work (as a team, of course)
  • Resilience: accept that errors will happen and make sure that they are not fatal, that you can live with them. This means also being aware of the risk involved in your changes

What happens in the team, in the team-work:

  • It enables a growing maturity, autonomy due to fast feedback, failing fast and early
  • It makes us real team-workers, “we fail together, we succeed together”
  • It leads to better programmers due to the need for XP practices and the need to know how to deliver backwards compatible software
  • It has an impact on the architecture and the design (see Accelerate)
  • Psychological safety: eliminates the fear of coding, of making decisions, of having code reviews
  • It gives a common goal, valuable for everybody: customers, devs, testers, PO, company
  • It makes everybody involved happy because of much faster feedback from customers instead of the feedback of the PO => it allows to validate the assumption that the new feature is valuable
  • It drives new ideas, new capabilities bc it allows experiments
  • Sets the right priorities: not to jump to code but to think about how to deliver new capabilities, to solve problems (sometimes even by deleting code)

How to start:

  • Agree upon setting CI/CD as a goal for the whole team: focus on how to get there not on the reasons why it cannot work out
  • Consider all requirements (safety net, coding and review practices, creating the pipeline and the quality gates) as necessary steps and work on them, one after another
  • Agree upon team rules making CI/CD as a team responsibility (monitoring errors, fixing them, flickering tests, processes to improve leaks in the safety net, blameless post-mortems)
  • Learn to give and get feedback on a professional manner (“I am not my work”). For example by reading the book Agile Conversations and/or practice it in the meetup

– – – – –

This bullet-point list was born during this year’s CITCON, a great un-conference on continuous improvement. I am aware that they can trigger questions and needs for explanations – and I would be happy to answer them 🙂