Lectures et publications de référence#

Cette page rassemble les livres, articles et publications importants qui sont mentionnés à travers l’ensemble du cours. Chaque entrée pointe vers la ou les sections où elle est discutée.

(Cette page sera enrichie au fur et à mesure que de nouvelles références seront intégrées dans le cours.)

Livres#

• Gerald Weinberg, The Psychology of Computer Programming (1971) : approche psychologique du développement logiciel, introduction de l’egoless programming → Module 2, Introduction, Module 2, L’intégration continue, Module 4, Scrum
• Fred Brooks, The Mythical Man-Month (1975) : réflexions sur la gestion de grands projets logiciels, dont la célèbre « loi de Brooks » → Module 1, Perspective historique, Module 6, L’économie du logiciel
• Andrew Hunt et David Thomas, The Pragmatic Programmer (1999) : conseils pratiques pour le développeur, origine du principe DRY → Module 3, Architecture et modularité
• Kent Beck, Extreme Programming Explained (1999) : manifeste de l’XP, origine de YAGNI et du TDD → Module 1, Perspective historique
• Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices (2003) : formalisation des principes SOLID, acronyme suggéré par Michael Feathers → Module 3, Architecture et modularité
• Robert C. Martin, Clean Code (2008) : principes de conception et de lisibilité du code → Module 3, Architecture et modularité
• Mike Cohn, Succeeding with Agile (2009) : la pyramide des tests → Module 2, Les tests
• David Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (2010) : formalisation de la méthode Kanban pour le développement logiciel → Module 4, Kanban
• Gang of Four (Gamma, Helm, Johnson, Vlissides), Design Patterns (1994) : catalogue fondateur des patrons de conception → Module 1, Perspective historique, Module 3, Architecture et modularité
• Martin Kleppmann, Designing Data-Intensive Applications (2017) : référence moderne sur les systèmes de données → Module 3, Les données
• Martin Fowler, Refactoring: Improving the Design of Existing Code (1999) : formalisation du refactoring comme discipline, mécanisme de remboursement de la dette technique → Module 4, Gestion de projet
• Ryan Singer, Shape Up (2019) : méthodologie de développement de Basecamp, approche asynchrone et “pitches” écrits → Module 4, Gestion de projet
• Matthew Skelton et Manuel Pais, Team Topologies (2019) : taxonomie des structures d’équipe et de leurs effets sur l’architecture logicielle, manœuvre de Conway inverse → Module 4, Gestion de projet
• Gene Kim, Kevin Behr et George Spafford, The Phoenix Project (2013) : roman fondateur du mouvement DevOps, parallèle entre lean manufacturing et livraison logicielle → Module 5, Introduction
• Gene Kim, Jez Humble, Patrick Debois et John Willis, The DevOps Handbook (2016) : formalisation des trois voies de DevOps (flow, feedback, apprentissage continu) → Module 5, Introduction
• Google (Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy), Site Reliability Engineering (2016) : formalisation des pratiques SRE, error budgets, on-call, postmortems → Module 5, Que faire quand ça casse ?
• Sidney Dekker, The Field Guide to Understanding Human Error (2006) : approche systémique des erreurs humaines, fondement de la culture « just culture » et des postmortems blameless → Module 5, Que faire quand ça casse ?
• Reid Hoffman, Blitzscaling (2018) : formalisation de la stratégie de croissance rapide des startups technologiques, tension entre vitesse et qualité → Module 6, L’économie du logiciel
• Michael Feathers, Working Effectively with Legacy Code (2004) : définition du legacy code comme code sans tests, techniques pour travailler sur du code existant → Module 6, Le métier de développeur

Essais et manifestes#

• Eric Raymond, The Cathedral and the Bazaar (1997) : comparaison des modèles de développement cathédrale (GNU) et bazar (Linux), loi de Linus → Module 6, L’open source
• Adam Wiggins, The Twelve-Factor App (2011) : douze principes pour concevoir des applications cloud-native, issus de l’expérience de Heroku → Module 5, Introduction, Module 5, Comment je le déploie ?

Articles et essais#

• Edsger W. Dijkstra, Cooperating Sequential Processes (EWD123, 1965) [texte] : le problème de l’exclusion mutuelle, le sémaphore qui le résout, et le dîner des philosophes qui montre ce que les verrous cassent à leur tour → Module 2, Ce qui casse
• C. A. R. Hoare, Communicating Sequential Processes (CACM, 1978) [texte] : des tâches qui ne partagent rien et ne s’échangent que des messages. Baptise le dîner des philosophes, et fonde la lignée qui mène à Go → Module 2, Ce qui casse, Module 2, Ne pas partager
• Jim Gray, The Transaction Concept: Virtues and Limitations (VLDB, 1981) [texte] : la transaction comme réponse de la base de données au même problème que le verrou résout dans le programme → Module 2, Ce qui casse, Module 3, Les données (stockage)
• Edward A. Lee, The Problem with Threads (IEEE Computer, mai 2006) [DOI] : les threads détruisent le déterminisme, c’est-à-dire ce qui permet de comprendre un programme en le lisant. À l’appui, son propre projet Ptolemy, relu par des spécialistes de la concurrence et couvert à 100 % par des tests, resté quatre ans sans incident avant de se bloquer le 26 avril 2004 sur un interblocage présent depuis le premier jour → Module 2, Concurrence et parallélisme, Module 2, Ce qui casse
• Carl Hewitt, Peter Bishop et Richard Steiger, A Universal Modular ACTOR Formalism for Artificial Intelligence (IJCAI, 1973) [texte] : l’acteur, un état que lui seul touche et une boîte aux lettres, cinq ans avant CSP et avec des messages asynchrones → Module 2, Ne pas partager
• Joe Armstrong, Making Reliable Distributed Systems in the Presence of Software Errors (thèse, KTH, 2003) [texte] : Erlang expliqué par son auteur, let it crash et les superviseurs. À lire aussi pour ce qu’elle dit des fameux neuf neuf de l’AXD301, dont la seule source était une présentation PowerPoint → Module 2, Ne pas partager
• Andrew Gerrand, Share Memory By Communicating (blogue de Go, 2010) [texte] : la formule de Go, ne communiquez pas en partageant la mémoire, partagez la mémoire en communiquant → Module 2, Ne pas partager
• Rich Hickey, Clojure Rationale [texte] : l’état mutable comme « désastre pour la concurrence », et l’immutabilité qui permet de « partager librement entre threads » → Module 2, Ne pas partager
• The Rust Programming Language, chapitre Fearless Concurrency [texte] : les erreurs de concurrence comme erreurs de compilation plutôt que d’exécution → Module 2, Ne pas partager
• QNX, System Architecture, chapitres sur le micronoyau et la communication entre processus [noyau, messages] : un système d’exploitation canadien où tout, jusqu’aux systèmes de fichiers, s’exécute hors du noyau et communique par messages synchrones → Module 2, Ne pas partager
• Sam Gross, PEP 703 : Making the Global Interpreter Lock Optional in CPython (2023) [texte] : la proposition qui défait un compromis vieux de trente ans, acceptée puis livrée en variante expérimentale. Le même code y devient trois fois plus rapide en threads, et révèle du même coup des bogues que le verrou masquait → Module 2, Processus et threads
• Gene Amdahl, Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities (AFIPS, 1967) [texte] : quatre pages qui fixent le plafond du parallélisme, la part séquentielle d’un programme bornant le gain quel que soit le nombre de processeurs → Module 2, Pourquoi la concurrence
• Gordon Moore, Cramming More Components onto Integrated Circuits (1965) [texte, DOI] : l’observation, sur deux pages, que le nombre de composants gravés sur une puce double à intervalle régulier. Moore y parle de quantité, jamais de vitesse → Module 2, Pourquoi la concurrence
• Robert Dennard et coll., Design of Ion-Implanted MOSFET’s with Very Small Physical Dimensions (1974) [DOI] : la loi de proportionnalité qui, en gardant la densité thermique constante quand les transistors rétrécissent, a converti la loi de Moore en gain de vitesse pendant trente ans → Module 2, Pourquoi la concurrence
• Herb Sutter, The Free Lunch Is Over (2005) [texte] : le moment où l’accélération cesse d’être offerte par le matériel et devient un travail de programmeur → Module 2, Pourquoi la concurrence
• Rob Pike, Concurrency Is Not Parallelism (conférence, 2012) [vidéo et diapositives] : la concurrence est une manière de structurer un programme, le parallélisme une manière de l’exécuter → Module 2, Pourquoi la concurrence
• Dan Kegel, The C10K problem (1999, mis à jour jusqu’en 2014) [texte] : la page qui pose le problème des dix mille connexions, et la division qui condamne le thread par client → Module 2, Ne jamais bloquer
• Node.js, About Node.js [texte] : Node décrit par lui-même, une boucle d’événements comme construction de l’environnement d’exécution plutôt que comme bibliothèque → Module 2, Ne jamais bloquer
• Ryan Dahl, Porting Node to Windows With Microsoft’s Help (blogue de Node, 2011) [texte] : le portage vers l’API IOCP de Windows, d’où est née libuv → Module 2, Ne jamais bloquer
• libuv, Design overview [texte] : la boucle au centre, liée à un seul thread, et les noms de Kegel, epoll, kqueue, IOCP, derrière une seule interface. Reprise par uvloop pour Python → Module 2, Ne jamais bloquer
• Barbara Liskov et Liuba Shrira, Promises : Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems (PLDI, 1988) [DOI] : le mot et l’idée, un objet qui représente un résultat pas encore arrivé, pour les systèmes distribués, vingt-sept ans avant leur entrée dans JavaScript → Module 2, Ne jamais bloquer
• Promises/A+ [texte] : le standard communautaire des promesses JavaScript, dont la première phrase est la définition à retenir → Module 2, Ne jamais bloquer
• Don Syme, Tomas Petříček et Dmitry Lomov, The F# Asynchronous Programming Model (PADL, 2011) [DOI] : l’origine d’async et await, chez Microsoft, avant C#, Python et JavaScript → Module 2, Ne jamais bloquer
• Guido van Rossum, PEP 3156 : Asynchronous IO Support Rebooted : the « asyncio » Module (2012) [texte] : la boucle d’événements de la bibliothèque standard, trois ans avant les mots-clés qui la rendent agréable → Module 2, Ne jamais bloquer
• Yury Selivanov, PEP 492 : Coroutines with async and await syntax (2015) [texte] : les coroutines comme fonctionnalité native de Python, clairement séparées des générateurs → Module 2, Ne jamais bloquer
• Python, documentation du module asyncio [texte] : « convient souvent parfaitement au code I/O-bound », et la fondation des serveurs web Python d’aujourd’hui → Module 2, Ne jamais bloquer
• FastAPI, Concurrency and async / await [texte] : quand écrire async def, expliqué avec des hamburgers, par le framework qui en dépend → Module 2, Ne jamais bloquer
• Node.js, documentation du module worker_threads [texte] : des threads « utiles pour les opérations intensives en calcul », et « peu utiles » pour les entrées-sorties, où la boucle fait mieux → Module 2, Ne jamais bloquer
• Edgar F. Codd, A Relational Model of Data for Large Shared Data Banks (1970) : article fondateur du modèle relationnel → Module 1, Perspective historique, Module 3, Les données (stockage)
• David Parnas, On the Criteria To Be Used in Decomposing Systems into Modules (1972) : introduction de l’information hiding → Module 3, Architecture et modularité
• Peter Naur, Programming as Theory Building (1985) : programmer comme construction d’un modèle mental → Module 2, Introduction, Module 6, Le développement assisté par IA
• Fred Brooks, No Silver Bullet (1986) : complexité essentielle vs accidentelle → Module 3, Introduction, Module 6, Le développement assisté par IA
• Melvin Conway, How Do Committees Invent? (1968) : la structure d’un système reflète celle de l’organisation qui le produit (loi de Conway) → Module 3, Architecture et modularité, Module 4, Scrum, Module 4, Gestion de projet
• Ward Cunningham, The WyCash Portfolio Management System (OOPSLA 1992) : introduction de la métaphore de la dette technique → Module 4, Gestion de projet
• Rob Pike, Notes on Programming in C (1989) : contient les « 5 règles de programmation » de Pike, dont la règle 5 sur la primauté des structures de données → Module 2, Survol rapide de la programmation
• Daniel Lemire, Python sets and dictionaries can have quadratic-time performance (blogue, 2026) [texte] : un professeur de la TÉLUQ montre, mesures à l’appui, que le temps constant des tables de hachage est un modèle, et comment le faire mentir avec des clés bien choisies → Module 2, Survol rapide de la programmation
• Brian Kernighan, UNIX For Beginners (Bell Labs, 7e édition du manuel Unix, 1979) [texte] : le débogueur adb « plutôt difficile à apprendre », et la phrase que cinquante ans n’ont pas démentie, « l’outil de débogage le plus efficace reste la réflexion attentive, accompagnée de quelques print judicieusement placés » → Module 2, Le débogage
• Barry Warsaw, PEP 553 : Built-in breakpoint() (2017) [texte] : un seul mot pour entrer dans le débogueur, et la variable d’environnement qui permet d’en changer sans toucher au code → Module 2, Le débogage
• Python, documentation du module pdb [texte] : le débogueur de la bibliothèque standard, points d’arrêt, pas à pas, inspection de la pile, mode post-mortem → Module 2, Le débogage
• Debugging with GDB, manuel de GDB, section Contributors [texte] : Richard Stallman, auteur d’origine du débogueur qui a fixé le vocabulaire de tous les autres → Module 2, Le débogage
• Smithsonian, National Museum of American History, Log Book With Computer Bug (1947) [fiche] : la mite du Mark II, « first actual case of bug being found », et le rappel qu’Edison parlait déjà de bugs dans les années 1870 → Module 2, Le débogage
• Donald Knuth, Literate Programming (The Computer Journal, 1984) [texte] : expliquer à des humains ce qu’on veut qu’un ordinateur fasse, plutôt que dire à l’ordinateur quoi faire ; l’idée dont le notebook est l’héritier le plus répandu → Environnements du cours
• John McCarthy, History of Lisp (1979) [texte] : la première démonstration de Lisp en temps partagé en 1960, le premier Lisp interactif de Deutsch en 1963, et l’anecdote du ramasse-miettes qui interrompt la démonstration → Environnements du cours
• Revenu Québec, Calcul des taxes [texte] : la TPS à 5 % et la TVQ à 9,975 %, toutes deux appliquées au prix de vente, la règle que la facture de la section sur le débogage viole → Module 2, Le débogage
• Edsger Dijkstra, Go To Statement Considered Harmful (1968) : plaidoyer pour la programmation structurée → Module 1, Perspective historique
• Edsger Dijkstra, On the foolishness of “natural language programming” (EWD667, 1979) : critique de l’idée de programmer en langage naturel, l’ambiguïté comme problème fondamental → Module 6, Le développement assisté par IA
• Martin Fowler, Continuous Integration (2006) : article de référence sur l’intégration continue → Module 2, L’intégration continue
• Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures (thèse de doctorat, 2000) : définition de REST → Module 3, Les APIs
• Roy Fielding, REST APIs must be hypertext-driven (billet de blog, 2008) : critique des APIs « REST » qui n’implémentent pas HATEOAS → Module 3, Les APIs
• Peter Deutsch et al., Fallacies of Distributed Computing (1994) : huit hypothèses fausses sur les systèmes distribués → Module 3, Les APIs
• Leonard Richardson, Richardson Maturity Model : classification des APIs REST en quatre niveaux de maturité → Module 3, Les APIs
• Jim Gray, contributions aux transactions et bases de données (prix Turing 1998) : formalisation des propriétés ACID → Module 3, Les données (stockage)
• Gerard Salton, A Theory of Indexing (1975) et le système SMART : père de l’information retrieval, concepts fondateurs de TF-IDF et de l’index inversé → Module 3, Les données (au-delà des BD)
• Google, Bigtable: A Distributed Storage System for Structured Data (2006) : article fondateur du stockage orienté colonnes à grande échelle → Module 3, Les données (stockage)
• Tomas Mikolov et al., Efficient Estimation of Word Representations in Vector Space (2013) : introduction de Word2Vec et des embeddings de mots → Module 3, Les données (stockage), Module 6, Le développement assisté par IA
• Marc Shapiro, Nuno Preguiça, Carlos Baquero et Marek Zawirski, Conflict-free Replicated Data Types (2011) : formalisation des CRDTs → Module 3, Les données (au-delà des BD)
• Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (2008) : livre blanc introduisant la blockchain et le consensus distribué → Module 3, Les données (au-delà des BD)
• Hirotaka Takeuchi et Ikujiro Nonaka, The New New Product Development Game (Harvard Business Review, 1986) : article fondateur qui introduit l’approche « rugby » du développement de produit, inspiration directe de Scrum → Module 4, Scrum
• Dave Thomas, Agile is Dead (Long Live Agility) (billet de blog, 2014) : critique de la récupération commerciale du mot “agile” par un des signataires du manifeste → Module 4, L’agilité
• Jez Humble et David Farley, Continuous Delivery (2010) : automatisation complète du chemin entre le commit et la production, concept du deployment pipeline → Module 5, Comment je le déploie ?
• John Allspaw, Blameless PostMortems and a Just Culture (2012) : formalisation de l’approche non punitive après les incidents, inspirée de l’aviation et de la médecine → Module 5, Que faire quand ça casse ?
• Netflix, Principles of Chaos Engineering (2014) : formalisation du chaos engineering, expériences en production pour tester la résilience → Module 5, Que faire quand ça casse ?
• Eric Brewer, Towards Robust Distributed Systems (keynote PODC, 2000) : formulation du théorème CAP (Consistency, Availability, Partition tolerance), prouvé formellement par Seth Gilbert et Nancy Lynch (2002) → Module 5, Est-ce que ça va tenir la charge ?
• Alan Turing, Computing Machinery and Intelligence (1950) : article fondateur posant la question “Can machines think?” et proposant le test de Turing → Module 6, Le développement assisté par IA
• Yoshua Bengio, Réjean Ducharme, Pascal Vincent et Christian Jauvin, A Neural Probabilistic Language Model (2003) : introduction des word embeddings appris conjointement avec un modèle de langage neuronal, fondation des LLM modernes → Module 6, Le développement assisté par IA
• Dzmitry Bahdanau, Kyunghyun Cho et Yoshua Bengio, Neural Machine Translation by Jointly Learning to Align and Translate (2014) : introduction du mécanisme d’attention, fondation du Transformer → Module 6, Le développement assisté par IA
• Ashish Vaswani et al., Attention is All You Need (2017) : introduction de l’architecture Transformer, brique de base de tous les LLM modernes → Module 6, Le développement assisté par IA
• Richard Gabriel, Worse is Better (1989) : essai opposant la philosophie “the right thing” (MIT/Lisp) à “worse is better” (Unix/C), la simplicité d’implémentation l’emporte sur la perfection → Module 6, Le métier de développeur