Lots has been said about Software Quality, often in highly abstract terms and relying on complicated concepts. Are we missing the point ? After roughly three decades of mulling over the issue, and lots of pain and suffering, I want to circle back to the core question: where do bugs come from ? I will show how we can combine insights into human nature with some of the heuristics I learned while exploring functional programming, and how, if we play our cards right, we can improve our software without putting our programming, designing and testing fates over to our new LLM overlords.

Let's explore the relationship between "giving or receiving feedback" and systems theory. Content warning: will discuss emotions; may come to unexpected conclusions.

Do you identify as a developer, a coach, a Product Owner, a Scrum Master ? This workshop aims to deconstruct these and other labels, and prompt deeper thinking about the roles we take on at work. Introspection can be difficult, but the process is designed to ensure your safety, and the reward is self-knowledge: a clearer view of the resources that you contribute to your professional community. The value of this session will be magnified by the diversity of its participants: please consider attending especially if you feel unsure of your place in this community or at work.

About the need of history in software ...

Are you yearning to write software that really matters to your users, software that does more than line corporate pockets and all too often turn into soul-grinding work? If that is what software craftsmanship means to you, I have an unusual proposition - work for the French government.

For most of you, government innovation probably sounds like an oxymoron. At best the words sound like an incongruous combination, like fish and chocolate. In the 2010 O'Reilly book Open Government Matthew Burton wrote: 'In recent years, the government has become almost completely dependent upon contractors for information technology (IT). So deep is this dependency that the government has found itself in a position that may shock those in the tech industry: it has no programmers of its own; code is almost entirely outsourced. (...) On top of keeping the government from innovating, the dependence on contractors hurts the country in much more tangible ways.'

This was written about the US government but applies equally well to France. Burton went on that the most skilled developers could be persuaded, out of a sense of civic aspiration, to lend governments these skills for a tour of duty. France, it turns out, is one of the countries to have recognized this as a great idea: we call it the State Startups, in French Startups d'Etat.

That may sound like yet another oxymoron. This talk is to convince you, in a short time so as not to risk boring anyone, that fish actually tastes good with chocolate - to entice you to try your hand at being a digital Hussar.

Here's a guilty secret of programming: a little debugging is a lot of fun. Granted, too much debugging can be the opposite of fun. Therein lies a mystery: why can't we ever seem to write just the right amount of bugs? The discipline tasked with answering these questions, known as Software Engineering has for the past four decades (and a bit) managed to ignore some fundamental facts about programming, such as why a little debugging can be a lot of fun, and more interestingly where bugs come from in the first place. Laurent's talk reveals some dismal truths about this sad state of affairs, but also offers more uplifting suggestions on how we can bring tons of fun back into programming, by developing new skills such as leprechaun hunting and brain debugging.