guillaume-st-etienne-larchitecture-vue-par-un-dev-de-2026

[00:00:00] Are we going to have sound? Sound, sound. It's good, great.
[00:00:12] One, two, three. One, two, three. Yes, it's working. Yes, it's good.
[00:00:48] Are you managing my time? I'm doing fine.
[00:00:52] Are you handling everything?
[00:00:55] I might set maybe...
[00:01:07] 5. 45? 45 minutes. Okay, in your group, does that make 2 rounds compared to 40? Yes, I see it clearly.
[00:01:18] I'll try to stick to my 45 minutes.
[00:01:22] Yes, that works.
[00:01:25] Alright, so, welcome again.
[00:01:29] Thank you, Flocon organizers, thank you, sponsors. I don't have a sponsor slide, but without them, conferences couldn't happen.
[00:01:41] I'm Guillaume Saint-Etienne, I'm going to talk to you about architecture. It was the topic I was asked to cover specifically for AlphaCode. My architecture for devs, from a dev's perspective, I took off, I judged it was time. So, my opinion is worth what it's worth. I'll tell you at the end.
[00:02:02] I've had the chance to work for ten and a half years on the Hyper project. I'm external, but I'm so proud of it that I mention it in every room. And indeed, whether it's Hyper or in software architecture or civil architecture, we're here to build things and, presumably, to make them last. That's the idea. Hence, the role of the architect has been known for... quite a long time, let's say, since we've been building solid or semi-solid structures, regardless of the style, regardless of the purpose.
[00:02:46] As for building software, people have been trying for a long time. We have founding fathers who first conceived computers and then tried to realize them. It was a bit simple at first, but all the theory, all the questioning, even philosophical, was there.
[00:03:09] And I like to cite Alan Turing for the particular role he played in history and how history has somewhat mistreated him, even though he was rehabilitated, fortunately, relatively recently.
[00:03:22] For my part, I'm not Alan Turing. I've certainly seen many things pass between my first lines of code here on this strange machine with its 64-kilobyte memory extension and a dreadful keyboard. It gets dark like that, so it takes into account the character you want to have.
[00:03:48] Up to today, I think like everyone else, Let's see, who doesn't use these tools? It will go faster. Very well. Thank you for your honesty.
[00:03:59] Building is a line. a dynamic constantly renewing itself, it's not the software industry, the software profession that does this, it's more the society we're immersed in, and it has been theorized, so I won't put Marx
[00:04:18] on a presentation image, but yes, because it's come back into fashion with the prizes.
[00:04:25] Recent Nobel Prizes in economics that indeed talk to us again about destructive construction and creative destruction, the two follow one another. And so do we, and even more rapidly, it's accelerating obviously since generative AI, where we're breaking everything while thinking about rebuilding everything.
[00:04:50] The role of architects in building all this is known, it's documented, and it's a matter of position. So, architects are people who have positioned themselves, who generally came from development. People who were promised a better future by becoming architects, because you understand, one can't stay a developer all their life. Either you become a manager, a boss, or there's still a place, if you still want to do some tech, as an architect, an enterprise architect. But enterprise architects have armed themselves, let's say, with a whole bunch of... Framework practices, ceremonies, a bit to establish a somewhat dominant position over what they were before, the simple rule.
[00:05:41] You have the right not to agree. And there are other architects who say, we want to stay a bit closer to what we produce, a bit less in the upper spheres and offices, and be a bit more on the ground. Hence their name. Craft Architect, that was me who came up with that. But it reflects a certain way of working. We will have architects who are more driven by quantitative metrics, dashboards, we didn't think about it, it's a bit like Excel, more focused on measuring productivity, time management, forecasts, schedules, etc. Velocities galore versus those who are more... And sometimes, it can be the same person, after all. Even in cases where they try to create architectures and refer to authoritative figures, for example, some who are raining down, well, who were rather authoritative. The book hasn't necessarily aged well, not everything in this book has aged well. And even people armed with this book have come back to say, I still need metrics, I need numbers, I will manage by the numbers. So I will replace my dashboards and tables. with other dashboards with others. In particular, we'll talk again about this debt issue, for example.
[00:07:13] So here's how we often see the architect, the famous Ivory Tower architect. This image speaks and will continue to speak because, well, even if it was generated yesterday, it's okay, it's okay.
[00:07:28] below, at the foot of the tower, there are fewer and fewer humans, thus, more and more agents. At least, humans supervising the agents, even if at some point, the architect ends up alone with their agents.
[00:07:45] This Ivory Tower position is maintained by a number of beliefs,
[00:07:57] commonly accepted things, or even things that companies will buy, will buy consulting from this methodology, this methodological framework, which places architects always in a position of ultra-decision-makers, just like business owners. And not too much in the team, although Safe, we say a lot of bad things about Safe, me first, but there's still something funny here, everyone forgot, it's that it advocates built-in quality. Built-in quality, it's in there, it's supposed to radiate, it says 'essential'. So, how is it essential? I find it a bit relegated to the corner.
[00:08:47] It's a matter of perspective.
[00:08:50] And so, these architects are, for me, business architects. They are very connected to the business. They think business, they breathe business, they churn out business and they make models, they love making models, super models of everything. Always with business everywhere. And they're right, in part, business is needed. to pay us well, first of all, the people who do it. But sometimes it leads to somewhat extreme things, in this case.
[00:09:24] However, I think that building software, whether architect or developer, we should place ourselves in a dynamic that includes business, but not only that. A dynamic that we could summarize in three points, which you know, I think. Build the right thing.
[00:09:42] Build it well, the right way, let's say in not too bad a way, and I would add with the right people.
[00:09:52] That's going to get interesting. So, building the right thing is the product, the right product. To decide what the right product is, we call on product management, people who know better than architects or who don't question their... Their knowledge, their know-how, their experience.
[00:10:15] They are connected both to the people who will do the delivery, who will build, and to all other stakeholders. They are really key, they are really important. Except they have a small connection window with us which is still only a sixth of the problem.
[00:10:34] And from the development teams' point of view, we can still have this slight feeling of being very nice, but staying in our place.
[00:10:45] And obedient, of course.
[00:10:49] Yet, product people aren't stupid. They have still abandoned the V lifecycle, the overly top-down things. They are more into... You are more... There are product people here. I don't have the hand, but... Not like that. So, you know this, you apply it, more or less, break it down, more, in my opinion, than less, break down a problem space
[00:11:18] and move to the solution space in short iterative loops to try, to learn from the experience of implementation, of going into production.
[00:11:32] In an effort, we come back to it, of destructive creation, but by design, in such a way as to improve, be faster to capture a market and more efficient.
[00:11:53] Domain-Driven Design takes up this idea and gives, I find, many more factual elements on how, to proceed from design, from strategy to tactics, implementation,
[00:12:10] in interconnected elements that communicate with each other, and thus in which the developer potentially has their place, even if they are sent a bit to the right of the diagram, But they have every right to be in the strategic part, since they are normally invited to workshops like event storming, impact mapping. They have their say. The dev team can also have, and not just architects, can have interesting views. That can impact the product strategy.
[00:12:49] It's not me saying it, it's him.
[00:12:52] This is a gentleman you may know, maybe not, it's Marty Cagan, an important guy from Silicon Valley, who came to Paris four years ago for the School of Product. And I ate across from him, I didn't know who he was. Someone told me, 'Are you crazy, that's Marty Cagan.' And then, I bought his books and then, I thought, he really says interesting things, in fact, for a product guy. His thing, for him, is products. It's products that change people's lives. He worked at Apple and all that. And in his latest book, Empowered, he says, you need engineers, product teams need engineers who have the means, who have power, and the power to decide as well.
[00:13:38] So, Empowered Engineers, who will build the right thing and do it well, thanks to technique.
[00:13:47] Technique, from the development point of view, do we see techniques?
[00:13:54] Sometimes, unfortunately, we don't see the product, we arrive, we're overwhelmed in a project, we see this, we see a code base, we see artifacts, we see rules, we see a wiki, a Confluence, sometimes a bit hard to follow.
[00:14:12] But that's it, we arrive in it, we might perceive... the elements if the code is designed with principles from the famous ubiquitous language, but sometimes we don't have it. And in any case, that's our daily life as developers, whether we're developers or about to be replaced. By our agent friends. It proceeds, we all work a bit on the same ground. From the AI's point of view, this ground is just context. It's everything needed to feed a prompt or to improve, or guidelines, or whatever you want, so that the AI agent can produce code that's roughly... Roughly, it's not great.
[00:15:02] And for us, humans, because we're still here, that's our bread and butter, it's our culture, it's much more than context. It's everything we started learning, because at first, we went through learning phases, whether in apprenticeship or in a public or private path. So, people initiated us into the culture of development. And this culture, through our experience, we have nurtured it because we added our own stones to the building and we discussed with people who had other ways of doing things. Maybe we also confronted other ways of doing things, something that was perhaps a bit rougher. Interaction between humans is rougher than with conversational agents, who always agree with us, but that's the problem.
[00:15:53] I'll come back to culture later. So, the architects of these artifacts are there, in my opinion, to nurture a culture already based on the solidity of what we will produce. Solidity based... On expertise and technical excellence around a whole set of practices, I think, which are now widely accepted, tests, the presence of tests, their automation, the fact that we think... that we guide design by tests, that we do clean code, etc. We can put this in CI-CD pipelines, we can't deliver without having fast feedback loops. All this, the purpose of an architecture is to produce things that are supposed to withstand time and thus be non-fragile, so as not to collapse over time. What's written on the left is generated by AI, it's not necessarily very advanced, somewhat technical examples. What interests me more is the diagram on the right, which doesn't come from architecture, it comes from sociology.
[00:17:10] But we find the same ideas. We need to innovate to be antifragile and we need to anticipate problems in a number of cases to be able to resist them. And adapt, and make our code adaptable, resistant, and not break
[00:17:35] at the first pressure that comes, whether it's pressure from a number of users, for example, or from someone who attacks, who created the solution, a feature that might have been poorly developed, a bug, etc.
[00:17:50] This desire for antifragility, we obtain it after having nurtured for years and years a... test culture. And when I started writing my first lines of code with this famous machine, you can well imagine that tests didn't exist. And for a very long time, unfortunately, I continued to learn to work with V lifecycles, with manual tests, and it lasted a very long time. At least, for my part, I wasn't lucky enough to arrive where TDD was widely... Implemented and still is, widely implemented in my recent experiences. I still feel like 1990 isn't that far away. I'm a bit sad, but there you go. We're trying to go back up, to redo the evolution path. At some point, evolution should...
[00:18:42] In history anyway, rather than starting over, starting over, but well, that's how it is, creative destruction, we said, but we're supposed, with each destruction, to climb a step.
[00:18:53] And we still get there, today, I think that, I hope to see, you're all used to,
[00:19:00] using AI and surely generating code with AI. And so, you save time and you normally have more time to write tests or have tests written. And agents are very, very good at writing tests. So, you see the future. On this slide, it's rather... I'll talk about it. More tests, going to do tests that at the time, it was... At the time, it was maybe only 3-4 years ago, where we said, against base testing, it's complicated, it's not for me, in my project, I can't do it. Mutation testing, yes, I've heard of it, but it's inapplicable. All that is no longer true.
[00:19:39] But I'll come back to it. You are all used to using AI and surely to working with AI-generated code. And so, you save time and normally have more time to write tests or have tests written. And agents are very, very good at writing tests. So, you see the future.
[00:19:15] On this slide, it's rather... I will talk about it.
[00:19:19] More tests, going back to testing like in the past, it was... Well, in the past, it was maybe only 3-4 years ago, before, when we thought that basic testing was complicated, it's not for me, in my project, I can't do it. Mutation testing, well yes, I've heard of it, but it's inapplicable. All of that is no longer true.
[00:19:38] But I will come back to it. Architecture also serves to create, to meet this need for solidity and thus to build confidence because when confidence is lacking, when I code and later, when I deliver, I can run into integration problems, performance issues,
[00:19:58] issues due to potential security flaws in my code or in the code of others that I use, inevitably, it's a problem and it's, we'll come back to a debt story,
[00:20:12] debt that exists or that we create ourselves, every time we write a line of code, we are adding our share of debt, in fact, to it.
[00:20:21] And as for the architect, I expect from them that... IMED should at least not continue to create debt and perhaps resolve it
[00:20:34] and facilitate this level of confidence that I should have when delivering code or when committing something to a branch that goes into the main branch, it would be better if it goes into a proof branch, it's better if we do trunk-based development
[00:20:50] So, we can expect this role of the architect who will instill confidence in their teams through a number of things. And we return to architecture principles. There are architects who say 'I will create an architecture.' And who have read Uncle Bob's book which is limited to a 'screaming architecture.' Something that screams in the faces of developers 'you must do it this way, you haven't respected this pattern and it blocks everything.'
[00:21:20] There are still people who strongly believe in this, who have really created software designs based on this, at the risk of it becoming really cumbersome. And anyway, and from having...
[00:21:33] I don't think... In any case, I have seen these architectures in place and I have especially seen developers spending their time bypassing
[00:21:41] Obviously, those where we had wanted to guide them. So, we can think that perhaps an architecture designed in a slightly lighter, less constraining way for developers, could also work. Worth trying. There are those who have already tried. So, the people, the people who build.
[00:22:02] The techs, and their experience as techs, or DevEx, the developer experience. Architects should care about it. They care a bit when they are delegated to recruitment, they take good care, they put themselves a bit in the position of people who arrive on... Their thing, their big project that many architects are convinced is great and was the best thing that could happen, but well, it's always a matter of perspective. And looking for all the small cards, all the elements of the Developer Experience, can question quite a bit the architect's work. Did we think it through well? The documentation stories, are the intentions clear, can a person onboard feeling somewhat comfortable with the codebase, etc. So, there are metrics for that. I will develop a few of them. At Google, they have a Google Developer Program.
[00:23:14] DX offers a dedicated framework for this.
[00:23:21] So, there are DevEx indicators that have appeared and which, for example, related to what was said in this morning's keynote, European metrics can find their place in a perhaps more interesting way as an indicator of what the developer feels rather than as a goal to achieve, but rather to measure if people are comfortable, if the techs are comfortable with their work and with their... With what was built by their architect. So, we can reuse DORA metrics and SPACE metrics to make them indicators of feeling, of user experience. So, that will be, it's numbers, so it's quantitative. Then, we can transform time to first deploy, so
[00:24:15] a developer who onboards, someone from the tech team who onboards, and their contribution, their first contribution, when will it be deployed? If it takes six months, because their work ends up in the pipelines, maybe something didn't go well. We can make them quality indicators. The slides, all the links are made available to you.
[00:24:41] And also, we can use qualitative indicators. We can do... And it would be good, and unfortunately, I haven't seen much of it, to do questionnaires, small surveys to take the pulse of... on factors that are sometimes subjective. But at least, for example, as a member of the tech team, do I feel that my decisions or my work have an impact on at least something? Am I just a simple executor and then it's up to the decision-maker to use these results or not?
[00:25:17] For us, on the developer side, all this still requires quite a bit of effort, on the tech side, it requires a lot of effort, a lot of effort that involves our brain, cognitive demands.
[00:25:34] Technical memory is our technical know-how, everything we have learned and everything we are still learning and the things we have forgotten too.
[00:25:45] We are also asked, even if it's less obvious, to have a memory beyond the technical,
[00:25:56] of what we find in the code, but which is much more than the application of patterns or certain syntaxes or certain programming styles. Regardless of the language and regardless of the style, a cognitive memory that, if it is defective, will cause problems when things are meant to change, or during refactoring or functional evolutions, and this memory deficiency will imply resistance to change, or show that the team has blocking points, that there are people who have captured certain knowledge and have not shared it. And as a result, things that will be very difficult to change.
[00:26:41] We also see phenomena of stress and burnout because either one is in charge of too many things in the code or in the technical parts, it rests too much on the shoulders of one person who doesn't necessarily those who want it, those who endure it.
[00:26:59] This is also found in onboarding, it's still a good... Everything that happens in onboardings, there is a set of metrics to dig into behind it.
[00:27:08] And also, developers, at some point, have access to a memory of the strategic context when they are given this information. When they are given it, because when it's missing, it creates debt. And there are three types of debt, in fact. Everyone is roughly aware of technical debt, but perhaps less of cognitive debt, and even less of context debt, which, in scope and impact, is growing, not what we do with the code, increasing, creating, or increasing or creating from all sides by agents.
[00:27:51] So, the architect must come to limit the debt, the debts, and first acknowledge that these debts exist. And this famous debt of intention,
[00:28:08] And intention is what happens a lot on the product management side. It's why, what are the real needs, what are the business objectives, the very culture of the client we serve through a product or software solution,
[00:28:25] which can become a real limiting problem. Do we even want to entrust, it's a fairly recent discussion, these elements, do we want to entrust them to agents? Well, we entrust them to agents, but do we want it to really leave the company? In any case, if we don't have it, we need to capture it. It must be part of the context. And then, however, we must avoid it leaking too much.
[00:28:55] So, here we are, developers and architects, managing not just technical debt, but debts. This is not a debt, it's a date. You don't have an image for debt.
[00:29:12] If you can redo nothing. Addressing the debt, so there is this paper that came out, I readapted my slides when I read this paper, it's quite interesting, so it's this person, Margaret, Margaret?
[00:29:29] Who highlights this notion of collective debt and context debt, the artifacts, we call them intention artifacts, since we develop faster
[00:29:42] and we also develop better, we noticed, I think everyone, that agents code better if we go through specifications first.
[00:29:53] I think we have done... Who has had the experience of doing specs? It's in the next slide. Start with the specs, see the specs written by AI, then do your code.
[00:30:06] Yes, a bit. And for those who haven't done it, try it. There are plenty of recipes. I'm not saying you have to use... I tried SpecKit. It was very disappointing. It's very verbose. It consumes tokens. There are other more homemade ways that work very well, such as for example... favoring executable specs, creating your own internal DSL, a Domain Specific Language. AI is very good at behavior-driven development, but I find that the Cucumber-Gherkin tandem is a bit cumbersome. It has always been cumbersome and it is still as cumbersome, even when processed by AI. So, my preference is for DSL, but that will be another topic. In any case, it will remain, these are artifacts that will remain. And thus, avoid losing this context. Except that this context needs to be maintained. This business context needs to be maintained.
[00:31:08] Ok.
[00:31:12] I am a great decoy.
[00:31:15] So, visually, this is how we work more and more. So, we have somewhat abandoned, at least for my part, it's true that people who are paired with agents, We have somewhat abandoned TDD. Already, it doesn't work. Doing TDD by the book with an agent doesn't work. Because it's not wired that way. It will provide the solution, the implementation, and the test at the same time. And you are against it. Wanting to make it do TDD the way we used to do it is not very interesting. However, the second part is... Yes, we need tests and we need even more tests. So, tests are even more present. They are not necessarily... Well, we will generate, precisely, we will have acceptance-like tests generated, but they can be unit acceptance tests. They will be isolated tests. I'm not talking about doing end-to-end testing. He says that everything should be specified, including a technical specification and that we should be able to trace the intention back to its origin and that this traceability is now in the code. It's the markdown. We no longer need to put this in...
[00:32:27] In information portals that are disconnected from the code, we can bring everything together. And thus, agents will feed on a much richer context and propose much more relevant code, to which we will add in our loop. So, these are loops that go very fast. So, we are doing extreme programming as we do this. We stay with this idea.
[00:32:55] To invest in things that seemed a bit out of reach, like automated performance testing, but also in terms of architecture, for example, automation.
[00:33:10] So, we can do many things and we must keep doing the right things.
[00:33:20] Good technical design choices are reflections and a choice that is a renunciation of what we will not keep. To be able to do this, it was mentioned a bit in this afternoon's keynote, we must make choices no longer too hastily and keeping in mind the impacts of these choices, knowing that all this is somewhat intertwined, that technology is under pressure from architecture, architecture itself is under pressure from business demands, but it is also a friction surface, if something goes wrong from a purely technical point of view, it forces a review of the architecture, and if we messed up things in the architecture,
[00:34:09] it will rub with the business people, we will say no, we cannot achieve everything you asked us, the way you asked us.
[00:34:20] So, we come to how to make these technical or architectural decisions.
[00:34:28] There is a process called the 'advice process,' which invites us to break down our decision-making into steps. Starting by targeting a problem, obtaining information that fuels reflection on the problem, defining choice criteria before choosing, even before choosing between several solutions, and that was discussed earlier, not too many solutions either, but having something quite... Maybe two choices, I don't know, is it too much, not too much, but sufficient, I don't know what the right number is, having evaluation matrices on the benefits-risks. Uh, deciding, we need to find out by which process we will decide. Is it by consensus? Is it by majority vote? Is it one person who decides for everyone? Document this. These decision-making processes fit well with formats that are widely accepted today.
[00:35:42] RFCs, does that speak to people, Requests for Comments? Not necessarily everyone. The Internet you use today was built on RFCs, so TCP, IP, SMTP, HTTP, all the protocols partly come from a
[00:36:01] long process of exchange, first, before reaching the decision. Requests for comment, they ask me, come comment on my proposal, what do you think, is it good, is it not good, it's debated, etc. Hence these states. And the ADR is there to finalize the architecture of this kind, and there, more for finalizing what was said during the RFC. And that too, is context for agents, very useful, at least the ADR. The RFC, I would see it more for humans, to try at some point to do archaeology, but why? Why did we end up here? What was said? Did we have the right decision criteria? Were there good discussions? Even if we have to start them again, but in any case, keeping the memory of this is mega important.
[00:36:49] It's not a luxury.
[00:36:52] Because to come to the decision-making then, OK, we have the options on the table, we have the right evaluation criteria, we need to decide. How? Brainstorming? We all think it's good, but actually, I took this from recent news, it's the guy who does Foloscopie, if you don't know his channel, it's really good. He was at the University of Grenoble, in addition. We had him live, it was great.
[00:37:22] And well, brainstorming, no. It's a bit slow, it's not necessarily, we took a study, scientific studies, compared to solo research.
[00:37:34] There is worse, in terms of decision-making, those famous architects who come to lock decisions.
[00:37:45] While other decision-making models emerge, those that encourage taking parliamentary parts and bringing everyone together to
[00:37:55] already discuss, but in a targeted way, rather oriented according to such a problem. We won't take the same impacted parties, and thus, it won't be the same experts we should solicit. And the person who makes the decision should not always be the same.
[00:38:14] This has been highlighted and is the subject of a book that I find quite fascinating. I'm almost halfway through.
[00:38:25] It's Andrew Armel Lowe's book, I pronounce it well, who started his reflection a few years ago on Martin Fowler's blog. You can find the essence of the book, the beginning of his reflection online, at this address. He had already published his thoughts on the advice process and the architectural advice process.
[00:38:53] Where do we do RFCs, where do we use RFCs, ADRs, do we set up a... A tech radar, this is largely detailed in the book, but it's available in this blog post.
[00:39:10] So, he advocates for decentralized decision-making that changes depending on the need and context as well. So each time, it's not the same groups of people for each decision. We take different groups of people depending on what the decision involves, so that it's faster. It's all in the book. And he also suggests creating advice forums, very easy to do on a GitHub or GitLab project, for example, and which are these discussions with voting mechanisms, etc. The hardest part too, I think, the architect's job,
[00:39:52] is to keep these discussions alive, because people won't necessarily go on their own. So, it needs to be fed.
[00:39:59] You can post something and then it will stay, there will be three discussions and then it will stop.
[00:40:05] And that's the portrait of what we can do today as devs and architects. And tomorrow? And tomorrow, what will our architects look like? Will it look like this? advice forums, very easy to set up on a GitHub or GitLab project, for example, and to have these discussions with voting mechanisms, etc. The hardest part, I think, is that the architect's job will be to keep these discussions alive, because people won't necessarily do it on their own, so you have to feed them, but not too much... You can post something and then it will just stay there, there will be three discussions and then it will stop.
[00:40:05] And that concludes the portrait of what we can do today as developers and architects. And tomorrow? And tomorrow, what will our architects look like? Will it look like this?
[00:40:26] That's too easy, I'm going too fast.
[00:40:29] To avoid ending up like this, I think we need to focus on a very sensitive point, which is the differentiation between context. We know that AIs are sensitive to context, whereas we humans,
[00:40:45] We are well beyond context. We live with our culture. And culture is something a bit complex, it's exchanges between humans, it's exchanges with what has been written, there is both dead matter and living matter, and above all, it has been nourished, it has been enriched, it stands the test of time, or not, by the way, things are said, the software architecture principles of the 2000s are no longer relevant today, and maybe that's good, but maybe it's not, I don't know.
[00:41:20] In any case, this culture allows us to express ourselves, even on technical subjects, with human strengths that can be real creativity and not just stochastic rambling. And also, something that agencies don't have is that we still manage to sense things. This intuition, this thing that cannot be mathematized, which makes us make a certain decision.
[00:41:49] Is this culture? it is maintained, it has existed for a long time, already in literary form. So there is a lot of literature on programming, the act of programming, writing code, whatever that code may be. We also find it now in many YouTube channels dedicated to it. And it also spreads into general culture, to the point that we find podcasts on national radio stations, generalist radio stations. Of quality, obviously.
[00:42:23] And if you don't know the podcast *Le Code a changé* on Radio France, I really invite you to go listen, it's super interesting. Even for developers, listening to how it's popularized, we will learn a lot. And by the way, there is an episode of the podcast, I think it dates back two years, on architecture, the civil architect, how civil architecture has been influenced by software. And since civil architecture is, after all, what we live in, and it models our cities, how software publishers like Autodesk and Ademi influence the organization of people in cities. It's quite crazy, you have to listen to it. And there is also, I came across this initiative by Thomas Petrisek, who is doing an exhibition on the culture of programming. So, I'm clicking a bit. It's an exhibition that is announced to be itinerant. I hope it will come to Paris and why not, it could be... its place at Flocon. He talked about cultures, and there, mathematical culture, software programming was born from math, the first thinkers, the first programs are essentially mathematical. Then, on top of that, the hacker culture is grafted, the engineer culture is grafted, the serious people. And even more serious people who want to make money and manage with the work of the people above.
[00:43:51] We must not forget that this culture is above all human, a human culture, with flaws that only humans can have. And he highlights a flaw that I learned something about, So, HyperCard, it's very old, it was for the first Apples, Apple II, Apple I, and the very first Macintosh. It was called Macintosh. It's a kind of ancestor of Excel that the guy coded while on an LSD trip, still. I didn't know, but I can well believe it, and it makes me laugh a lot. For many, this is subculture.
[00:44:24] So, us architects with a culture,
[00:44:31] and a culture made of techniques and exchanges between people, so socio-technical or techno-social, we've already talked about it throughout the day,
[00:44:45] And I thought, wait, what could culture be in the future? It turns out I like science fiction and I started reading some space operas a bit late, including one in particular called *The Culture series*. It struck my mind. And in *The Culture series*, this author, there is a bank that knows.
[00:45:10] I haven't read it all the way through because it's a space opera, it's a saga. But the Culture is a new civilization that does not dominate the universe but still has an important place, which is very wise, which is a kind of... There are AIs in it, there are neo-humans, post-humans. It has infinite wisdom, it also has a lot of humor. And so, I asked a current AI, if we mixed architects, my story of architectural culture with the Culture of Banks' books, here's what it told me, we could indeed imagine the architects of the Culture, these kinds of... being a bit of a super scholar, who sees the world. But the architects of the Culture, from science fiction, they have certain characteristics, they have certain characteristics. So they are against hierarchization. They are post-human, that could be said.
[00:46:14] They have power, but they don't like to show it too much.
[00:46:18] They know how to intervene, they would know how to intervene at the right time. However, when the Culture intervenes, it's better not to be in the battlefield because it is not belligerent, but the Culture is not a very...
[00:46:36] The Culture builds great projects, it's a mega civilization based on permanence and sustainability.
[00:46:49] So, our software architects could draw inspiration from this aspect of the Culture. So, this was generated by a rambling, by a fusion of people. The last line, I had to change it because it told me 'which avoids driving another human to suicide in 5 years?' 'Oops!' That's not politically correct, but because it's a bit violent in the books. So, the mix went a bit off track. Oh, but it was funny.
[00:47:22] It's AI ramblings, but I found it radically pacifist with coders. Uninterpretable with debt, the enemy is debt, the enemy is not the developer, but maybe it's some... We see this in some companies, unfortunately, we wonder who the enemy is, if it's the people who work or if it's the real flaws in the product. So, thanks to the philosophy of the Culture, so the Culture with a capital C, we could see things differently, especially stop blaming developers, not being code police, which is something difficult. To stick to it.
[00:47:59] We said competent, but who knows how to step back. We find this in initiatives that are a few years old. I really liked April Denzel's initiative on compassionate coding. I code for others, I don't code for myself.
[00:48:13] And we're almost at the end. No heavy processes, no architecture that yells at people, light processes.
[00:48:24] Eliminate useless rituals and still accept mistakes, but with things that allow us to see mistakes more quickly and then fix them.
[00:48:40] the pragmatic side is well aligned. And I will finish on an unexpected note. In the Culture, the society of the Culture has a lot of humor, self-deprecation about itself. And because people, Yann Bans believes that brilliant people are above all people who don't take themselves too seriously, who are fun, who bring fun into what they do. There are super fun things that the Culture does.
[00:49:05] For a whole bunch of benefits. For example, if you want to be like the Culture, you could name internal hardware, I was about to say, things that users won't see, class names, package names, server names, whatever you want. In the style of what we find in the Culture's books.
[00:49:31] And it's quite funny. Listen, I'm right. It's none of your business. I'm the mediator.
[00:49:38] And there, we understand quite well.
[00:49:42] More AI ramblings, I find this super funny. So, we do what we want. Thank you, that was the little conclusion.

Transcript (Translated)