https://remihuguet.devRSS for NodeTue, 18 Feb 2025 08:19:48 GMT It’s that way for a reason: most everything that the media publishes about startups is a lie (or at least missing so much of the story that it’s indistinguishable from a lie). ]]>https://remihuguet.dev/blog/2017/09/24/veille-de-la-semaine-n-1https://remihuguet.dev/blog/2017/09/24/veille-de-la-semaine-n-1Sun, 24 Sep 2017 00:00:00 GMTThere is a small group of people for whom code speaks. They discovered more than a job, they discovered a calling. Code is a craft and they are artists. For every one of those folks there are thousands of amazing, solid developers that will write circles around 90% of the other CS graduates. But they aren't "the best." >Ezekiel Bucheit — No, I have no side code project to show you ### [From an internal Basecamp announcement re: pings/IMs](https://m.signalvnoise.com/from-an-internal-basecamp-announcement-re-pings-ims-e0f61ec9e3bd) Un article comme souvent très pertinent de Jason Fried sur les communications en entreprise. Cette fois, il s'attaque à cette habitude stupide que beaucoup d'entre nous ont pu avoir à l'occasion sur les messageries instantanées: sonner l'interlocuteur via un message inutile, et attendre un retour pour déliver l'information que l'on souhaite communiquer … ]]>https://remihuguet.dev/blog/2017/10/29/les-liens-de-la-veille-6https://remihuguet.dev/blog/2017/10/29/les-liens-de-la-veille-6Sun, 29 Oct 2017 00:00:00 GMTThe problem is that software engineers don’t understand the problem they’re trying to solve, and don’t care to,” says Leveson, the MIT software-safety expert. The reason is that they’re too wrapped up in getting their code to work. “Software engineers like to provide all kinds of tools and stuff for coding errors,” she says, referring to IDEs. “The serious problems that have happened with software have to do with requirements, not coding errors.” Les solutions mises en avant par l'article sont discutables, mais je crois qu'il pose les bonnes questions et les bons enjeux, et donne des éclairages intéressants sur les solutions expérimentées. Un dernier passage, juste pour troller sur les IDE >Visual Studio is one of the single largest pieces of software in the world,” he said. “It’s over 55 million lines of code. And one of the things that I found out in this study is more than 98 percent of it is completely irrelevant. All this work had been put into this thing, but it missed the fundamental problems that people faced. And the biggest one that I took away from it was that basically people are playing computer inside their head. ### Startups #### [Good by Cozy](https://blog.addictedtointer.net/2017/09/26/goodbye-cozy/) Franck Rousseau, co-fondateur et ex CTO de Cozy Cloud, délivre un retour d'expérience très intéressant. #### [What’s a Tech Company?](https://salon.thefamily.co/whats-a-tech-company-515960d76c21) Nicolas Colin propose un cadre pour définir une société tech, sur la base de critères assez simples. Un travail très interessant, qui soulève de nombreuses questions, notamment sur l'usage des data clients et la vie privée. ### Sideways #### [Douze mythes de l’intelligence artificielle](http://www.oezratty.net/wordpress/2017/douze-mythes-intelligence-artificielle/) Si comme moi vous êtes une bille sur la question de l'IA, mais que vous flairez le washing médiatique permanent, cet article est un super debunk très documenté et instructif sur le sujet. ]]>https://remihuguet.dev/blog/2017/10/08/veille-de-la-semaine-n-3https://remihuguet.dev/blog/2017/10/08/veille-de-la-semaine-n-3Sun, 08 Oct 2017 00:00:00 GMThttps://remihuguet.dev/blog/2017/10/21/les-liens-de-la-veille-n-5https://remihuguet.dev/blog/2017/10/21/les-liens-de-la-veille-n-5Sat, 21 Oct 2017 00:00:00 GMThttps://remihuguet.dev/blog/2017/10/01/veille-de-la-semaine-n-2https://remihuguet.dev/blog/2017/10/01/veille-de-la-semaine-n-2Sun, 01 Oct 2017 00:00:00 GMTPeople in our industry think they stopped doing waterfall and switched to agile. In reality they just switched to high-frequency waterfall. >Ryan Singer Comme souvent avec les contenus des gens de Basecamp, les articles sont très bien faits (illustrés et tout). Et pour ne pas gâcher, parce que Basecamp est une belle boîte avec des valeurs solides, le fond est en général à la hauteur. C'est le cas de cet article, mais je vais vous avouer un truc: j'ai partagé dès que j'ai vu la phrase ci-dessus, sans lire la suite. ### [5 conseils pour mettre en place une culture produit dans une startup BtoB](https://medium.com/nerds-hopwork/5-conseils-pour-mettre-en-place-une-culture-produit-dans-une-startup-btob-1f09316e1dce) Un chouette article plein de bon conseils pour les startups B2B. Je valide et signe des deux mains. ### [Startup Mistakes: Choice of Datastore](https://www.stavros.io/posts/startup-mistakes-datastore/) Allez hop, un petit contenu de plus dans le grand retour de bâton contre les base de données NoSQL qui a commencé il y a quelques temps. Il n'est évidemment pas question de tomber dans l'excès inverse. Chaque solution a un cas d'usage. Mais avec un peu de recul, force est de constater que la frénésie MongoDB il y a quelques années à fait un paquet de dégats. Quand les choix sont dictés par la hype, ça finit en général mal … ### [Au sujet de l’école 42 et de la publicité dont elle bénéficie](http://binaire.blog.lemonde.fr/2017/11/09/au-sujet-de-lecole-42-et-de-la-publicite-dont-elle-beneficie/) >Enseigner à une infime minorité sélectionnée est facile. La question difficile est celle de l’enseignement de masse, surtout si celui-ci doit déboucher sur des emplois >David Monniaux Je n'ai rien contre l'école 42. Vraiment. Mais quand la médiocrité journalistique d'un chroniqueur des Échos (Dominique Seux) rencontre la hype marketing du digital, ça donne du grand n'importe quoi. Cette mise au point salutaire de David Monniaux remet les choses à leur place: l'enseignement de l'informatique par le service public existe depuis plus de 50 ans en France. La multiplication des écoles privées du domaine répond surtout à une opportunité commerciale de vendre des formations de qualités variables. L'école 42 est, elle, gratuite. Mais d'une part, elle ne forme qu'une ultra minorité — elle ne résoudra pas le manque de compétences à elle seule — et d'autre part, elle doit encore démontrer qu'elle obtient des résultats. ## Les autres liens - [Declining Complexity in CSS](http://meyerweb.com/eric/thoughts/2017/11/14/declining-complexity-in-css/) - [HTML & CSS Is Hard (But it doesn’t have to be)](https://internetingishard.com/html-and-css/) - [Betting on the web](https://joreteg.com/blog/betting-on-the-web) - [2018's Software Engineering Talent Shortage — It’s quality, not just quantity](https://hackernoon.com/2018s-software-engineering-talent-shortage-its-quality-not-just-quantity-6bdfa366b899) ]]>https://remihuguet.dev/blog/2017/11/28/les-liens-de-la-veille-9https://remihuguet.dev/blog/2017/11/28/les-liens-de-la-veille-9Tue, 28 Nov 2017 00:00:00 GMT In a ‘user first team’, the next thing to work on would actually be determined by this question: ‘What can we do next to make the users most satisfied?’. >Ariel Verber — The problem with roadmap first teams #### [Full-Stack Developers](http://bradfrost.com/blog/post/full-stack-developers/) Brad Frost nous livre une réflexion non dénuée d'intérêt sur la notion de développeur full-stack. Un sujet qui revient régulièrement, tout comme celui des titres des différents développeurs, et les bisbilles entre "frontenders" et "backenders" (voir par exemple [ce thread sur Twitter](https://twitter.com/ppk/status/918122287940997120)). ### Startups #### [Startup jungle: la foire aux accompagnements](https://medium.com/skwid/startup-jungle-la-foire-aux-accompagnements-b78bdf2cb324) Un retour d'expérience et un point de vue bienvenue sur les startups et surtout les structures d'"accompagnement". *TL;DR: elles ne servent à rien, pour la plupart.* Voilà, bonne lecture. > C’est un véritable symptôme, surtout chez les non-tech, de se dire “oh mon dieu sans la tech j’y arriverai jamais”, ce qui est complètement faux. In fine, le véritable problème de tout business, c’est la vente : vous ne réussirez pas si personne n’achète, point. Et, non, ce n’est pas en écrivant un business plan que vous vendrez mieux 🤔. >Guillaume Odier, Startup Jungle: la foire aux accompagnements #### [Interview en toge - S01- EP02 - Damien MORIN - Save](https://youtu.be/_8MbB4raGg8) Dans cette interview assez longue, Damien Morin raconte avec beaucoup de détails intéressants l'histoire de Save. Si vous ne connaissez pas Save, c'est une entreprise qui répare des téléphones, et qui a beaucoup fait parler depuis deux ans. D'abord pour avoir eu une croissance délirante sur l'année 2015, et une surprésence médiatique de son CEO Damien Morin. Ensuite pour avoir connu une procédure de sauvegarde à l'été 2016. Cela avait donné lieu à un déferlement de critiques et d'articles truffés de bêtises, à la hauteur du buzz absurde autour de Damien Morin quand tout allait bien. #### [Marcel de Publicis, ou le chant du cygne d’une industrie](https://www.theangle.fr/2017/10/02/marcel-de-publicis-ou-le-chant-du-cygne-dune-industrie/) Quand Publicis essaye d'aborder sa propre "transformation digitale", ça fait peur … ]]>https://remihuguet.dev/blog/2017/10/15/veille-de-la-semaine-n-4https://remihuguet.dev/blog/2017/10/15/veille-de-la-semaine-n-4Sun, 15 Oct 2017 00:00:00 GMThttps://remihuguet.dev/blog/2017/12/18/les-liens-de-la-veille-10https://remihuguet.dev/blog/2017/12/18/les-liens-de-la-veille-10Mon, 18 Dec 2017 00:00:00 GMThttps://remihuguet.dev/blog/2017/11/13/les-liens-de-la-veille-8https://remihuguet.dev/blog/2017/11/13/les-liens-de-la-veille-8Mon, 13 Nov 2017 00:00:00 GMThttps://remihuguet.dev/blog/2018/02/07/les-liens-de-la-veille-12https://remihuguet.dev/blog/2018/02/07/les-liens-de-la-veille-12Wed, 07 Feb 2018 00:00:00 GMThttps://remihuguet.dev/blog/2018/01/15/les-liens-de-la-veille-11https://remihuguet.dev/blog/2018/01/15/les-liens-de-la-veille-11Mon, 15 Jan 2018 00:00:00 GMThttps://remihuguet.dev/blog/2018/02/25/les-liens-de-la-veille-13https://remihuguet.dev/blog/2018/02/25/les-liens-de-la-veille-13Sun, 25 Feb 2018 00:00:00 GMThttps://remihuguet.dev/blog/2018/04/04/les-liens-de-la-veille-14https://remihuguet.dev/blog/2018/04/04/les-liens-de-la-veille-14Wed, 04 Apr 2018 00:00:00 GMTa startup is an organization formed to search for a repeatable and scalable business model. (_NB: Passez un peu de temps à creuser et à adopter cette grille de lecture. On devient beaucoup plus sain d'esprit, et on comprend beaucoup mieux ce qui se passe une fois qu'on l'a adopté..._) Cette définition pose le caractère profondément expérimental, faillible et temporaire (_search for..._), et le type d'entreprise que cela produit (_repeatable and scalable_). C'est un type extrêmement précis, et réduit, d'entreprise. Toutes les nouvelles entreprises innovantes ne sont pas dans un processus de découverte d'un modèle de création de valeur. Toutes les jeunes entreprises n'ont pas pour vocation de se dupliquer à l'international, ou d'atteindre la scalabilité, ou les deux. Toutes les entreprises qui cherchent de nouveaux modèles de création de valeur ne vont pas forcément être répétables. Ou scalables. Il est parfaitement légitime de vouloir développer une entreprise qui reste à dimension humaine, ou locale, ou ce que vous voulez. Ce n'est pas parce que vous levez des fonds que vous êtes une startup. Et inversement. Heureusement que toutes les jeunes entreprises ne sont pas des startups. Ce serait invivable. Et heureusement qu'il existe des startups, avec des ambitions débordantes, des réussites étonnantes et des échecs retentissants. Le monde est vaste, et il faut de tout. Et vous n'avez sans doute pas besoin de croire que vous êtes une startup si vous ne l'êtes pas. ]]>https://remihuguet.dev/blog/2019/10/18/vous-n-etes-pas-une-startuphttps://remihuguet.dev/blog/2019/10/18/vous-n-etes-pas-une-startupFri, 18 Oct 2019 00:00:00 GMT If you don’t explain what you’re actually testing, you force the reader (possibly future you) to deduce the main intent by looking at all of its properties. Hyneck explique dans cet article pourquoi il a mis en place une politique visant à commenter 100% des tests dans les projets open-source dont il s'occupe. Même si l'idée me paraît un peu extrême, il a de bons arguments. ## [Python Developer Survey 2019 results](https://www.jetbrains.com/lp/python-developers-survey-2019/) Les résultats de l'étude 2019 de la Python Software Foundation sont arrivés. Si on agrége data science et machine learning dans une même catégorie (spoiler: on peut), c'est aujourd'hui le principal cas d'usage des utilisateurs de Python (31%), devant le développement web (28%). Mais ce qui m'interpelle le plus dans cet étude, et cela est lié à l'incroyable essor de la data science ces dernières années, c'est le niveau d'expérience des répondants: 69% (!) ont moins de 5 ans d'expérience en tant que développeur professionnel. A méditer. ## [Savoir faire des choses compliquées ne fait pas de vous un bon développeur](https://www.lilobase.me/savoir-faire-des-choses-compliquees-ne-fait-pas-de-vous-un-bon-developpeur/) >[...]j’ai pu observer, dans certaines communautés et entreprises, une certaine propension à glorifier des solutions particulièrement compliquées [...] Malheureusement, ce que ces gens prouvent, c’est qu’ils sont capables de travailler dans un contexte de très forte charge cognitive. [Arnaud Lemaire](lilobase.me) écrit une série d'articles sur la complexité logicielle, que je vous conseille de suivre. L'obsession d'une partie de notre industrie pour la complexité, pour ne pas dire son fétichisme, est un problème que l'on doit affronter. Oui, certains profils de "brilliant jerk", et la fascination qu'ils peuvent exercer, constituent un énorme problème. ]]>https://remihuguet.dev/blog/2020/05/17/les-liens-complexite-logicielle-and-experiencehttps://remihuguet.dev/blog/2020/05/17/les-liens-complexite-logicielle-and-experienceSun, 17 May 2020 00:00:00 GMThttps://remihuguet.dev/blog/2020/05/15/pareto-et-qualite-logiciellehttps://remihuguet.dev/blog/2020/05/15/pareto-et-qualite-logicielleFri, 15 May 2020 00:00:00 GMThttps://remihuguet.dev/blog/2020/05/17/la-force-des-habitudeshttps://remihuguet.dev/blog/2020/05/17/la-force-des-habitudesSun, 17 May 2020 00:00:00 GMThttps://remihuguet.dev/blog/2020/01/31/au-revoir-eshard-bonjour-independanthttps://remihuguet.dev/blog/2020/01/31/au-revoir-eshard-bonjour-independantFri, 31 Jan 2020 00:00:00 GMTIf you go this way, you’re beset by the cognitive dissonance of following in the footsteps of enormous projects [...] but being far outside the norms of modern web development. If Wikipedia were started today, it’d be React. Maybe? >What if everyone’s wrong? We’ve been wrong before. Tiens, le temps du backslash pour les SPA (single page applications) semble arrivé. Parmi d'autres, une des contributions récentes sur le sujet. Tom MacWright fait le constat que la stack moderne - Single Page Application, React et API - pose énormément de problèmes quand on l'utilise pour tout et n'importe quoi sans discernement. C'est une bonne chose d'en prendre conscience. Dommage l'on doive passer par un cycle de hype supplémentaire pour se souvenir, encore une fois, qu'il n'y a pas de balle en argent en ingéniérie logicielle. Les solutions techniques résilientes ne se batissent pas à coup de hype, mais avec du pragmatisme. ## [The properties of great architecture](http://www.ouarzy.com/2020/05/17/the-properties-of-great-architecture/) >Then defining good software with practices or tool is definitely a failure. [...] >It won’t be great just because you’re OOP code base is SOLID. >It will be great only if both people building it and people using it are happy. Only if they feel whole when they use or build it. [Ouarzy](http://www.ouarzy.com/) se pose la question de ce qui fait qu'un logiciel semble bon ou pas, notamment à l'aide d'un parallèle avec l'architecture de bâtiment. Le parallèle est intéressant, et on arrive rapidement à la conclusion qu'un logiciel, comme un bâtiment, ne peut être jugé qu'en tant que système complexe, intégré à son environnement. ]]>https://remihuguet.dev/blog/2020/05/25/les-liens-modern-web-et-architecturehttps://remihuguet.dev/blog/2020/05/25/les-liens-modern-web-et-architectureMon, 25 May 2020 00:00:00 GMThttps://remihuguet.dev/blog/2020/05/24/des-hauts-et-des-bashttps://remihuguet.dev/blog/2020/05/24/des-hauts-et-des-basSun, 24 May 2020 00:00:00 GMThttps://remihuguet.dev/blog/2020/06/04/parlez-moi-de-vos-problemeshttps://remihuguet.dev/blog/2020/06/04/parlez-moi-de-vos-problemesThu, 04 Jun 2020 00:00:00 GMThttps://remihuguet.dev/blog/2020/06/23/cherissez-votre-legacyhttps://remihuguet.dev/blog/2020/06/23/cherissez-votre-legacyTue, 23 Jun 2020 00:00:00 GMTIn fact, all things being equal the technology, no matter how good, is more than likely trivial in the grand scheme of things. It is the problems that the technology solves that really matters at the end of the day and no one cares how elegant or inelegant it is. >David Karapetyan ### [React explained to a Vue.js developer](https://medium.com/@pierrericgarcia/react-explained-to-a-vue-js-developer-73afa7e8fb6f) Un petit article technique sympathique dans lequel l'auteur expose les similarités et différences d'implémentation de différents comportements entre deux des frameworks d'interface à la mode, React et Vue.js. ### En vrac Les autres liens de la semaine, en vrac: - A ne pas rater: [I’d Like You To Know the Definition of Agile…](https://medium.com/@JoshuaKerievsky/id-like-you-to-know-the-definition-of-agile-639d3fd29d54) - [Developers are the Most Underrated Designers](https://hackernoon.com/developers-are-the-most-underrated-designers-5855a7e4aa2c) - [Don’t Build a Startup, Build a Movement](https://medium.com/swlh/dont-build-a-startup-build-a-movement-15c31213168) ]]>https://remihuguet.dev/blog/2017/11/03/les-liens-de-la-veille-7https://remihuguet.dev/blog/2017/11/03/les-liens-de-la-veille-7Fri, 03 Nov 2017 00:00:00 GMThttps://remihuguet.dev/blog/2020/06/25/choix-et-compromishttps://remihuguet.dev/blog/2020/06/25/choix-et-compromisThu, 25 Jun 2020 00:00:00 GMThttps://remihuguet.dev/blog/2020/06/22/links-python-and-morehttps://remihuguet.dev/blog/2020/06/22/links-python-and-moreMon, 22 Jun 2020 00:00:00 GMThttps://remihuguet.dev/blog/2020/07/09/l-analyse-strategique-au-secours-du-legacyhttps://remihuguet.dev/blog/2020/07/09/l-analyse-strategique-au-secours-du-legacyThu, 09 Jul 2020 00:00:00 GMTIf you needed COVID-19 to figure out that the people working to stock supermarket shelves had a hard job, that nurses were completely overworked, what were you looking at? COVID-19 didn’t start all of this, it just made it impossible to ignore. Bon ok il ne s'agit pas vraiment de software. Mais je dois avouer que j'ai une faiblesse pour les gens de chez The Family, et Oussama Ammar a un point de vue intéressant dans cet article - et comme souvent, une punchline bien sentie. ]]>https://remihuguet.dev/blog/2020/06/16/les-liens-ddd-thinking-async-et-covidhttps://remihuguet.dev/blog/2020/06/16/les-liens-ddd-thinking-async-et-covidTue, 16 Jun 2020 00:00:00 GMTThere is an approach to design that many, if not most, developers adopt unthinkingly. Let’s call it Code Driven Design. It’s the process we’re likely to follow automatically; the path of least resistance. Nice article by David Seddon about his personnal software design process. In my experience, a good part of software developpers' issues originates in a lack of a clear and structured methodology. So here is one to inspire you. ## [The alternative to roadmaps](https://svpg.com/the-alternative-to-roadmaps/) I've discovered the Silicon Valley Product Group blog pretty recently, and I became some sort of fan boy instantly. This piece is already five years old and is inspiring. In a nutshell, the alternative is: 1. Empowered, autonomous teams with some form of OKR 2. High integrity commitments (https://svpg.com/managing-commitments-in-an-agile-team/) ## [Property-based testing and hypothesis in python](https://www.hillelwayne.com/post/property-testing-complex-inputs/) Property-based testing is some complicated word for a simple idea: some part of your software presents properties that can always be verified. In Python, hypothesis is a library to achieve easily that type of tests. The funny part is, I had already used hypothesis and made some property-based testing without realising it, up until I read this article! It was kind of a "ahah" moment, since I finally understood why hypothesis is clearly not suitable for all tests in Python. ## [The most famous loop](https://danco.substack.com/p/the-most-famous-loop) Alex Danco's newletter _Two truths and a take_ is great. This one is very interesting. He elaborates an analogy between thermodynamic's Carnot cycle loop and business loops, with one powerful idea: _expansion and contraction of disorder is an essential part of efficient loops._ A must read! ## [UI as an afterthought](https://michel.codes/blogs/ui-as-an-afterthought) This post explains how one should model and design front-end software, starting from state and processes, rather than from UI. Stated differently, Domain Driven Design apply to front-end development too ;) ## [Fast design will kill your product](https://philip.design/blog/fast-design-will-kill-your-product/) As a software engineer, and sometimes team lead, I often feel odd when stakeholder (CEO most of the time) ask me to put some small changes on top of our backlog. Most of the time, justification is: "it's a quick win". And yes, sometimes these are real wins, quick to implement - but not all. The problem is, how can you keep a consistent product design when you are taking a lot of fast design decisions ? This post is a concise explanation of why you should be very careful when doing fast design. I'd add that you should be careful with quick wins - sometimes it is not really quick, and sometimes it's not even a win... ## [#NOESTIMATES - La fin des estimations ?](https://www.youtube.com/watch?v=fZXV9YeAFnY&feature=emb_logo) (in french) A great video by Frédéric Leguedois about estimates in software development. Full of interesting considerations - and a lot of punchlines! ## [India, Jio, and the Four Internets](https://stratechery.com/2020/india-jio-and-the-four-internets/) >On one hand, large U.S. tech companies are winners, at least relative to everyone else: yes, all of the regulatory red tape increases costs (and, for targeted advertising, may reduce revenue), but the impact is far greater on would-be competitors. To put it in allegorical terms, the E.U. is restricting the size of the castle even as it dramatically increases the moat. In this Stratechery issue about TikTok, Ben Thompson describes the different Internet models, from US to China and European one. Obviously, his opinion on EU model strikes me: yes, we are gaining more and more protection for citizens. But it comes at a cost, that is not recognised explicitly most of the time: these regulations are barrier for new incumbents. The same regulations that are protecting us citizens are also preventing us to grow our own Internet giants, and thus let us completely dependent of US techs. Maybe the most effective way to fight against GAFAM in EU would be to have our own GAFAMs. ]]>https://remihuguet.dev/blog/2020/09/17/2020-summer-s-linkshttps://remihuguet.dev/blog/2020/09/17/2020-summer-s-linksThu, 17 Sep 2020 00:00:00 GMThttps://remihuguet.dev/blog/2020/12/29/un-bilan-de-2020https://remihuguet.dev/blog/2020/12/29/un-bilan-de-2020Tue, 29 Dec 2020 00:00:00 GMT[...] there is a step beyond thinking of yourself as x but tolerating y: not even to consider yourself an x. The more labels you have for yourself, the dumber they make you. J'aime beaucoup les écrits de Paul Graham en général et je viens de découvrir cet article un peu ancien. Une argumentation plutôt convaincante sur l'idée suivante: il est à peu près impossible d'avoir une discussion rationnelle sur un sujet que quelqu'un a intégré a son identité. Donc, pour être plus rationnel et plus ouvert, gardons notre identité la plus simple possible. ## [The Most Important Thing | Silicon Valley Product Group](https://svpg.com/the-most-important-thing/) >Empowerment of an engineer means that you provide the engineers with the problem to solve, and the strategic context, and they are able to leverage technology to figure out the best solution to the problem. Un très intéressant, et court, article de Marty Cagan, du [Silicon Valley Product Group](https://svpg.com/). La vision du product management que partage Marty Cagan sur ce blog est bluffante - et cet article parvient à synthétiser une idée très forte de façon simple. Un autre article brillant: [Product vs. Feature Teams](https://svpg.com/product-vs-feature-teams/) ## [Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY](https://saagarjha.com/blog/2020/05/10/why-we-at-famous-company-switched-to-hyped-technology/) >Initially, we tried messing with some garbage collector parameters we didn’t really understand, but to our surprise that didn’t magically solve our problems so instead we disabled garbage collection altogether. This increased our memory usage, but our automatic on-demand scaler handled this for us, as the graph below shows Une parodie bien sentie, et plutôt drôle, des articles que l'on peut voir régulièrement fleurir au sujet des changements de stack technique dans telle ou telle startup financée. Une des multiples facettes de l'obsession malsaine de notre milieu pour ses joujous: les technos. ]]>https://remihuguet.dev/blog/2020/06/01/les-liens-identite-produit-et-hypehttps://remihuguet.dev/blog/2020/06/01/les-liens-identite-produit-et-hypeMon, 01 Jun 2020 00:00:00 GMThttps://remihuguet.dev/blog/2021/01/12/crise-et-recrutement-de-profils-juniorshttps://remihuguet.dev/blog/2021/01/12/crise-et-recrutement-de-profils-juniorsTue, 12 Jan 2021 00:00:00 GMThttps://remihuguet.dev/blog/2021/01/15/clean-architecture-with-djangohttps://remihuguet.dev/blog/2021/01/15/clean-architecture-with-djangoFri, 15 Jan 2021 00:00:00 GMT- Ça marche, mais on a des problèmes de qualité parce qu'on a pas de tests automatisés. >- Pourquoi il n'y a pas de tests automatisés? >- [Manager machin] nous a demandé de ne pas les faire pour sortir plus vite, et on nous accorde jamais le temps pour rattrapper la situation. On est pas écouté. La première étape pour être écouté et pris au sérieux est d'assumer ses responsabilités. Si on a délivré quelque chose dont la qualité est en-dessous des attentes, implicites ou explicites, c'est notre responsabilité. _Bien sûr, il y a des organisations profondément dysfonctionnelles et de mauvaix managers._ Pour autant, nous devons assumer notre responsabilité: nous produisons le logiciel, c'est donc à nous de garantir qu'il est conforme au niveau de qualité attendu - explicite si possible, implicite souvent. Si on juge indispensable d'avoir une suite minimale de tests automatisés, la première étape est de ne pas donner prise sur cet élément lors de la négociation de périmètre. (Sidenote: _c'est un des effets de bord intéressant du développement dirigé par les tests: l'obtention d'une couverture minimale de tests n'est pas négociable._) Si on a livré en conscience en-dessous du niveau de qualité qu'on pense nécessaire, c'est notre responsabilité. Pour être considéré comme des adultes et pris au sérieux dans l'organisation, commençons par nous comporter en adulte. ]]>https://remihuguet.dev/blog/2020/06/01/la-responsabilite-du-developpeurhttps://remihuguet.dev/blog/2020/06/01/la-responsabilite-du-developpeurMon, 01 Jun 2020 00:00:00 GMThttps://remihuguet.dev/blog/2021/01/18/learning-is-the-software-engineer-jobhttps://remihuguet.dev/blog/2021/01/18/learning-is-the-software-engineer-jobMon, 18 Jan 2021 00:00:00 GMT“Ce que montre le dilemme de l’innovateur, c’est que l’avantage des start-up n’est tant pas leur agilité que le fait qu’elles n’ont pas d’activité historique à protéger”. Pourtant, les grandes organisations sont la première source de revenus des vendeurs de méthode Agile, [SAFe](https://www.scaledagile.com/enterprise-solutions/what-is-safe/) en tête, pour une agilité à l’échelle clé en main : tout est fait pour assurer la grande organisation contre le risque. ## _“Run, you fool!”_ Ces dérives ont des conséquences délétères sur les équipes. Elles sont dénoncées depuis plusieurs années, en premier lieu par des signataires du manifeste. Dans [Agile is Dead (Long Live Agility)](https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html), Dave Thomas, signataire du manifeste et auteur du classique “The pragmatic programmer”, est direct : >"The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products." Scrum, par la volonté de ses créateurs, est devenu un standard Agile de fait. Les témoignages sur les dégâts d’une application sans recul de ces préceptes sont nombreux. La charge de [Michael O’Church](https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/) est l’une des plus virulentes : >“Scrum is the worst, with its silliness around two-week “iterations”. It induces needless anxiety about microfluctuations in one’s own productivity. There’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. It just makes people nervous. There are many in business who think that this is a good thing because they’ll “work faster”. Pourtant, les acteurs sur le terrain sont de bonne volonté et de bonne foi. L’agilité est demandée par les équipes, les directions y voient l’opportunité d’une amélioration du fonctionnement de l’organisation, les facilitateurs veulent vraiment aider. Alors comment en arrive-t-on à cette situation ? C’est le paradoxe (apparent) de l’agilité. Vouloir imposer une méthode Agile vous éloigne de l’agilité, parce que vous entrez directement en contradiction avec le premier principe du manifeste. **“Individuals and interactions over processes and tools”** L’agilité packagée - de Scrum à SAFe, mais pas seulement - permet de rassurer des décideurs averses au risque, et des opérationnels mal à l’aise avec l’incertitude. Avec ses rituels et ses pratiques, un framework Agile est une solution miracle à des problèmes complexes. Mais cela n’a plus grand-chose à voir avec le manifeste, et - surtout - avec les besoins des organisations et des équipes. ## Accepter la complexité Les managers doivent sortir du faux confort d’une méthode toute prête et affronter l’incertitude du terrain. Être agile peut être un bon moyen d’atteindre vos objectifs - mais cela n’est pas garanti. Pour cela, foin de méthode toute faite, de framework et de rituels. Pour une organisation “tech”, c’est-à-dire pour qui le logiciel est au centre de la création de valeur, vouloir que l’organisation soit Agile n’est pas un objectif. Ce que vous souhaitez, c’est créer plus de valeur : augmenter le chiffre d’affaires, le bien-être des salariés, la satisfaction des utilisateurs, la marge, ou n’importe quel objectif qui fait sens dans votre contexte. Bien identifier ces objectifs, les décliner dans une vision et des missions pour chaque équipe est un bon point de départ. Charge ensuite à chaque équipe de s’organiser, comme le rappelle Ron Jeffries dans [Developers Should Abandon Agile](https://ronjeffries.com/articles/018-01ff/abandon-1/) : >"The Manifesto calls for “self-organizing” teams, and in the best case, that comes down to the team choosing its own process. If I were starting a company, I’d let the teams choose any process they wish. I’d ask for results, not a specific process" Il faut partir du terrain : des gens, du contexte, et utiliser la boîte à outils des méthodes pour construire la meilleure solution, [comme l'explique Dave Thomas](https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html) : >"What to do: Find out where you are Take a small step towards your goal Adjust your understanding based on what you learned Repeat How to do it: When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier." Mettre en place des équipes autonomes, donner le contexte stratégique et la vision, et permettre à l’équipe de construire ses solutions pour atteindre les objectifs de l'organisation est un pas vers une organisation agile. ## Au fondement ... ou pas Utiliser aveuglèment une méthode Agile est en contradiction fondamentale avec le manifeste. Si cela fonctionnait, ce ne serait pas bien grave - on se fiche de la fidélité au dogme originel. Mais appliquer des méthodes Agile prêtes à l’emploi fait beaucoup de dégâts, et bien souvent cela crée plus de problèmes que cela n’en résout. Commencez par identifier les objectifs véritables de votre organisation. Il est indispensable de mettre les mains dans la complexité et travailler au plus près du terrain, donner des objectifs, une vision et des moyens à des équipes autonomes, capables de s’organiser pour délivrer des résultats. Si vous êtes une organisation dont le logiciel est au cœur de la proposition de valeur, l’agilité, c'est à dire la capacité à s'adapter à un environnement d'incertitude - commence par l’excellence technique. C’est souvent la grande oubliée des projets de transformation - et c’est pourtant le fondement à bâtir en premier. _Je remercie Marie-Laure Kléville, Frédéric Bourguignon et Valentin Decker pour leurs relectures et avis sur cet article. Que ce soit le premier d’une longue série._ ## Des liens cool Voici quelques ressources en lien avec le sujet: - [Et si on redémarrait l'agile ? Arnaud Lemaire](https://www.youtube.com/watch?v=pLISFJM22ro&t=3s) - [Allen Hollub “War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile”](https://www.youtube.com/watch?v=WFbvJ0dVlHk) - [“Running in circles” Basecamp, Shape Up](https://m.signalvnoise.com/running-in-circles/) - [Why Agile isn’t working, John Cutlefish](https://cutle.fish/blog/why-isnt-agile-workin) - Les articles du [SVPG](https://svpg.com) - https://svpg.com/lead-with-context-not-control/ - https://svpg.com/the-alternative-to-roadmaps/ - https://svpg.com/meaningful-transformation/ ]]>https://remihuguet.dev/blog/2021/06/02/pour-etre-agile-ne-deployez-pas-la-methode-agilehttps://remihuguet.dev/blog/2021/06/02/pour-etre-agile-ne-deployez-pas-la-methode-agileWed, 02 Jun 2021 00:00:00 GMThttps://remihuguet.dev/blog/2021/06/12/pourquoi-les-choix-techniques-se-sont-pas-si-importantshttps://remihuguet.dev/blog/2021/06/12/pourquoi-les-choix-techniques-se-sont-pas-si-importantsSat, 12 Jun 2021 00:00:00 GMThttps://remihuguet.dev/blog/2021/01/21/how-to-start-clean-architecture-with-djangohttps://remihuguet.dev/blog/2021/01/21/how-to-start-clean-architecture-with-djangoThu, 21 Jan 2021 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/04/estimations-astrologiehttps://remihuguet.dev/blog/2023/01/04/estimations-astrologieWed, 04 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/03/dynamique-equipehttps://remihuguet.dev/blog/2023/01/03/dynamique-equipeTue, 03 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/05/temperature-eauhttps://remihuguet.dev/blog/2023/01/05/temperature-eauThu, 05 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/08/365-challenge-bilanhttps://remihuguet.dev/blog/2023/01/08/365-challenge-bilanSun, 08 Jan 2023 00:00:00 GMTFirst principles thinking is the act of boiling a process down to the fundamental parts that you know are true and building up from there. Lorsque nous sommes confrontés à un problème ou avons une tâche à accomplir, nous cherchons d’abord une solution toute prête dans notre expérience. C’est une forme d’économie d’énergie du cerveau : cela consomme beaucoup moins de ressources d’utiliser une expérience passée, une recette déjà apprise, de fonctionner par analogie ou par imitation. Et heureusement que nous fonctionnons ainsi. Nous ne pouvons pas en permanence inventer de nouvelles solutions. Être capable de sortir de ce mode est pourtant important. Vinita Bansal dans [First Principles Thinking: The Most Powerful Way To Think](https://www.techtello.com/first-principles-thinking/) écrit: >When faced with complicated problems at work or in life, they are inclined to follow a safe path to known practices and do not attempt a hard path that requires digging deeper and exploring unknown territory. Utiliser le raisonnement par les principes premiers est d’autant plus difficile et exigeant que l’on n’a pas l’habitude de le pratiquer. Cela peut même être inconfortable, car comme l’écrit Vinata Bansal, cela nécessite une rupture dans les croyances courantes et le dogme: >A shift in thinking that discards conventional wisdom, cuts through the dogma and questions our own beliefs. Pour cette raison, c’est aussi un excellent moyen de forger une pensée critique et originale : prendre l’habitude de décortiquer les problèmes, d’identifier les hypothèses implicites ou non, conserver uniquement celles que l’on ne peut pas déduire plus avant, construire sur ces bases. >If you want to enhance an existing process or belief, continuous improvement is a great option. If you want to learn how to think for yourself, reasoning from first principles is one of the best ways to do it. >*James Clear* Comment le raisonnement par les principes premiers m’a-t-il aidé depuis que je suis développeur logiciel ? ## Et l’ingénierie logicielle ? Commençons par la réponse franche : je ne sais pas vraiment. J’ai quelques pistes, des débuts de compréhension, beaucoup de questions en suspens. La chose dont je suis sûre, c’est que ma méthode de travail et de raisonnement m’a permis de compenser les manques inhérents à un autodidacte. Il se trouve que le développement logiciel est dominé par la méthode de travail par analogie et imitation. Ce n’est pas étonnant, c’est le mode dominant que l’on apprend à l’école. Cela reste par ailleurs une étape pédagogique probablement indispensable. Pourtant, je suis toujours surpris de voir à quel point ce milieu semble attaché à des pratiques qui me paraissent mauvaises. Il faut connaître un certain nombre d’algorithmes (les fameux tests au tableau blanc…), connaître les designs pattern du Gang Of Four[^6], connaître l’API de tel framework, … Lorsque l’on doit résoudre un problème, le réflexe par défaut semble être de copier quelque chose qui y ressemble vaguement. Le succès de Stack Overflow, et les innombrables mèmes et blagues sur le “Stackoverflow driven development”, constitue les meilleures preuves que, pour encore trop de développeurs, la discipline consiste surtout à imiter. Ce n’est pas un mal en soi. Parfois, imiter ou utiliser une solution toute prête est la meilleure chose à faire. Il m’arrive d’utiliser Stack Overflow, pour trouver de nouvelles pistes sur un problème ou me documenter. Les problèmes surviennent quand c’est le seul mode de fonctionnement que l’on connaît. J’ai l’intuition, la conviction même, qu’il y a beaucoup à gagner à apprendre à travailler selon les principes premiers. Ne serait-ce qu’un peu. Comme le dit Jame Clear, “aller un ou deux niveaux plus profond que la plupart des gens”[^5] suffit pour tirer un avantage d’utiliser le raisonnement par les principes premiers. Mais comment l’utiliser dans le cadre de l’ingénierie de logiciels ? Si je regarde ma propre pratique, j’ai quelques pistes. La première application la plus évidente est pour la résolution de problèmes, en particulier le debug. Dans le cadre de la résolution de bug, c’est une méthode terriblement efficace, qui ressemble à une démarche expérimentale. Une façon de commencer à utiliser le raisonnement par les principes premiers dans ce cadre est de : - rassembler les faits et observables dont on dispose (logs, capture d’écran, …) - décortiquer et expliciter toutes les hypothèses et préconceptions implicites que l’on a sur le contexte - identifier et écarter impitoyablement tout ce qui n’est pas fondé - pour chaque hypothèse restante, déterminer un processus et une méthode de vérification empirique Ce mode de pensée peut aussi être utilisé pour la recherche de solutions innovantes à un problème. Analyser de façon systématique les différentes composantes d’un problème, identifier et porter un œil très critique sur les hypothèses faites apporte déjà un plus pour la conception de solutions. La deuxième piste concerne l’apprentissage. Pour un développeur, apprendre est une composante essentielle du métier. Utiliser le raisonnement par les principes premiers permet d’apprendre à apprendre vite, et de développer une plasticité qui permet d’adopter rapidement de nouveaux outils ou technologies. Je fais en sorte de toujours m’approprier les concepts en déconstruisant, reformulant, et refaisant par moi-même. Il existe une tendance dans toute spécialité de noyer les concepts importants sous des montagnes de complexité artificielle et de bruit. Lorsque j’aborde un nouveau sujet, j’essaie d’identifier les principes fondamentaux sous-jacents, et de le séparer des détails. Par ailleurs, je me limite à quelques sources de documentation. J’utilise en général abondamment les documentations officielles. Je suis peu de cours en ligne, de tutoriels, et lis assez peu de livres techniques. En la matière, l’important n’est pas la quantité mais la qualité. Chaque lecture doit s’accompagner d’un travail de pratique et de reformulation, qui est très chronophage. Reste la conception et l’architecture logicielle au sens large. J’ai pour l’instant des intuitions sur la façon dont le raisonnement par les principes premiers m’aide dans ce domaine. La méthodologie en elle-même apporte un regard différent sur l’architecture ou la conception de code. Au-delà de la méthodologie, la question qui se pose est : quels sont les principes de conception fondamentaux ? Classiquement, nous pouvons citer les suspects habituels : SOLID, KISS, DRY[^7], principes du Domain Driven Design, les designs pattern du Gang Of Four, … Certaines de ces pratiques sont sans doute des principes premiers. D’autres désignent déjà des notions composites, qui peuvent se déduire de principes plus fondamentaux. Le jour où l’on doit résoudre un problème qui sort un peu du cadre, nous serons mieux armés si nous comprenons les principes fondamentaux qui ont permis de construire ces concepts. Je ne sais pas quels sont ces principes. Ils ne sont probablement pas universels d’ailleurs, mais dépendent du problème étudié, du contexte et du niveau d’abstraction où l’on se place. J’ai quelques intuitions et idées, mais trop confuses encore pour les partager. Je suis convaincu que l’utilisation plus large du raisonnement par les principes premiers dans la communauté de l’ingénierie logicielle et formuler, diffuser et enseigner des principes fondamentaux pourrait aider à améliorer la pratique et l’apprentissage du métier. ## Une méthode qui gagne à être connue Pour expliquer le résultat négatif des expériences de Michelson et Morley, Albert Einstein est revenu aux principes les plus fondamentaux. Sur cette base, il a écrit l’article de physique le plus fascinant de l’histoire de cette science, et changé notre compréhension de la physique et la façon dont on pratiquait la discipline. Sans avoir la prétention d’avoir autant d’impact, cette façon de raisonner peut nous aider au quotidien dans notre métier de développeur. Elle nécessite un investissement, et comme toute pratique nouvelle nécessite du temps pour s’acquérir et être efficace. Bien utilisée, elle permet d’apprendre à mieux apprendre, d’apporter des solutions innovantes à des problèmes complexes. Je pratique cette façon de travailler en tant que développeur depuis quelques années maintenant. Que ce soit pour apprendre et me former, pour résoudre des bugs, pour aborder des problèmes complexes, cet héritage de mon passé de physicien a été mon meilleur atout en tant que développeur. Je suis convaincu que la formulation claire, la diffusion des principes premiers de l’ingénierie logicielle, l’apprentissage de l’utilisation de ses méthodes, peut bénéficier à tous les développeurs. Mon espoir, sans doute naïf et arrogant, est que cela pourrait être une contribution pour résoudre en partie la “crise” du logiciel, ces problèmes permanents de qualité rencontrés par notre industrie depuis 40 ans[^8]. [^1]: On la qualifie de “restreinte” car elle exclut la prise en compte de la gravitation, sujet qui sera abordé par Einstein plus tard, en 1915, à travers la relativité dite générale. [^2]: Pour une description des expériences, voir [Wikipedia](https://fr.wikipedia.org/wiki/Exp%C3%A9rience_de_Michelson_et_Morley). [^3]: Pour une version française de l’article, voir par exemple [cette traduction](http://etienneklein.fr/wp-content/uploads/2016/01/De-l%C3%A9lectrodynamique-des-corps-en-mouvement.pdf). [^4]: Attribué à Richard Feynman: *"Understand, don’t memorize. Lean principles, not fomulas."* [^5]: D'après [James Clear](https://jamesclear.com/first-principles): *"In practice, you don’t have to simplify every problem down to the atomic level to get the benefits of first principles thinking. You just need to go one or two levels deeper than most people."* [^6]: Désigne le livre “Design Patterns - Elements of reusable Object-Oriented software” par E. Gamma, R. Helm, R. Johnson et J. Vlissides en 1994. [^7]: Dans l'ordre: - **SOLID** : désigne 5 principes de conception en programmation orientée objet, formulée par Robert C. Martin : Single responsibility principle, Open / Closed principle, Liskov susbtitution principle, Interface segregation principle, Dependency inversion principle. - **KISS**: *Keep it simple, stupid* - **DRY**: *Don’t Repeat Yourself* [^8]: Vous remarquerez que, contrairement à A. Einstein, je fais pas mal de notes de bas de page. ]]>https://remihuguet.dev/blog/2021/06/12/relativite-logiciel-principeshttps://remihuguet.dev/blog/2021/06/12/relativite-logiciel-principesSat, 12 Jun 2021 00:00:00 GMTWe all make the same mistake here: we push (or at least accept) a culture in which we teach and learn tools as go-to solutions without teaching to identify and face problems.]]>https://remihuguet.dev/blog/2021/07/14/newsletter-1https://remihuguet.dev/blog/2021/07/14/newsletter-1Wed, 14 Jul 2021 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/16/software-craft-avant-proposhttps://remihuguet.dev/blog/2023/01/16/software-craft-avant-proposMon, 16 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/17/software-craft-avant-proposhttps://remihuguet.dev/blog/2023/01/17/software-craft-avant-proposTue, 17 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/21/pair-prog-pas-simplehttps://remihuguet.dev/blog/2023/01/21/pair-prog-pas-simpleSat, 21 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/09/lundi-matinhttps://remihuguet.dev/blog/2023/01/09/lundi-matinMon, 09 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/25/piliers-du-crafthttps://remihuguet.dev/blog/2023/01/25/piliers-du-craftWed, 25 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/06/deploiement-vendredihttps://remihuguet.dev/blog/2023/01/06/deploiement-vendrediFri, 06 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/26/resiliencehttps://remihuguet.dev/blog/2023/01/26/resilienceThu, 26 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/11/apprenez-tddhttps://remihuguet.dev/blog/2023/01/11/apprenez-tddWed, 11 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/31/vrai-ou-pashttps://remihuguet.dev/blog/2023/01/31/vrai-ou-pasTue, 31 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/10/plainte-non-qualitehttps://remihuguet.dev/blog/2023/01/10/plainte-non-qualiteTue, 10 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2023/01/22/get-togetherhttps://remihuguet.dev/blog/2023/01/22/get-togetherSun, 22 Jan 2023 00:00:00 GMThttps://remihuguet.dev/blog/2025/02/07/game-of-life-cursorhttps://remihuguet.dev/blog/2025/02/07/game-of-life-cursorFri, 07 Feb 2025 00:00:00 GMThttps://remihuguet.dev/blog/Invalid%20date/Invalid%20date/Invalid%20date/slughttps://remihuguet.dev/blog/Invalid%20date/Invalid%20date/Invalid%20date/slughttps://remihuguet.dev/blog/2025/02/17/problems-agilehttps://remihuguet.dev/blog/2025/02/17/problems-agileMon, 17 Feb 2025 00:00:00 GMThttps://remihuguet.dev/blog/2025/02/18/janvier-stoichttps://remihuguet.dev/blog/2025/02/18/janvier-stoicTue, 18 Feb 2025 00:00:00 GMThttps://remihuguet.dev/blog/2025/02/18/ai-remplacement-devshttps://remihuguet.dev/blog/2025/02/18/ai-remplacement-devsTue, 18 Feb 2025 00:00:00 GMT Si vous faites du développement logiciel, vous ferez des bugs. > Un logiciel qui n'a pas de bug est un logiciel qui ne change pas. > Corriger un bug peut provoquer d'autres bugs, alors il ne faut pas forcément se précipiter pour le faire. > Les bugs sont inévitables. C'est normal de corriger de nombreux bugs après avoir fait une nouvelle fonctionnalité. J'entends régulièrement ce genre de phrase, où une forme plus ou moins proche. Je peux difficilement clamer haut et fort que ces assertions sont fausses. Effectivement, personne de raisonnable dans notre industrie ne peut prétendre produire du logiciel **zéro bug**. Pourtant ces phrases me gênent. Je connais le niveau moyen de qualité produit dans les équipes où je suis passé. Je vois, en tant qu'utilisateur, le niveau moyen des applications que j'utilise tous les jours. Je sais que, dans la majorité des contextes, nous pourrions éviter 80 % des bugs en adoptant quelques pratiques. Je suis gêné donc quand j'entends ces phrases. Elles montrent une forme d'acceptation de la médiocrité moyenne des logiciels que nous utilisons tous les jours, et ce que nous produisons. Nous pouvons faire mieux. Nous devrions avoir l'ambition de progresser, pas simplement faire toujours plus, mais faire mieux. ]]>https://remihuguet.dev/blog/2023/01/12/zero-bughttps://remihuguet.dev/blog/2023/01/12/zero-bugThu, 12 Jan 2023 00:00:00 GMT Cet utilisateur a entré dans le tableur une liste de 15 critères classés en fonction de ses goûts et de ses besoins. Un exercice > hautement subjectif, soit dit en passant. Et lorsque la journaliste de The Economist le lui fait remarquer, sa réponse est sans > appel : > > “Une estimation chiffrée sera toujours mieux que rien.” Je croise cette idée très souvent, y compris (et surtout) dans le cadre professionnel. J'ai régulièrement entendu très exactement cette phrase sur un sujet logiciel (je vous laisse deviner...) Je la trouve dangereuse. Cette obsession pseudoscientifique des chiffres sert essentiellement à se rassurer à coups de rationalité discount. Il est dangereux de manier les chiffres, les datas, les métriques, sans avoir des cadres conceptuels, des modèles prédictifs, des cadres d'interprétations bien définis. Un chiffre n'est rien, n'a aucune signification. Nous avons d'autant plus tendance à leur attribuer trop d'importance dans le logiciel parce que c'est une discipline technique, voire qui semble scientifique. Parfois, il vaut mieux aucun chiffre qu'un chiffre arbitraire. Je vous laisse apprécier la suite : > Jacob, c’est le nom de ce fondu d’Excel, évalue ses rencontres en mettant une note pour chaque critère puis le multiplie par un coefficient spécifique, ensuite, il les additionne et obtient une note finale de 0 à 10. Un chiffre qu’il juge fiable, car il élimine de l’équation les émotions et autres faiblesses de l’amour. Mais au bout du compte, il a eu beau faire appel à toutes les fonctionnalités d’Excel, Jacob n’a pas réussi à départager les deux femmes les mieux notées. C'est une parabole 😇 ]]>https://remihuguet.dev/blog/2023/01/15/chiffrehttps://remihuguet.dev/blog/2023/01/15/chiffreSun, 15 Jan 2023 00:00:00 GMT