prévisions à "design patterns", bien que toutes les soient trois orthogonales, tandis que la programmation extrême est une stratégie de projet. Cependant, l'histoire a montré que la maîtrise de certaines tactiques modèle fortement la stratégie qui, à son tour, redéfinit les possibilités tactiques. Les grands polémologues n'ont-ils pas toujours éclairé leurs exposés sur la stratégie par des exemples tactiques. Ainsi, issues d'un même mouvement de fond dont on peut faire remonter l'origine aux années soixante avec Simula et Smalltalk, les quatre approches se renforcent mutuellement et présentent des points communs dus à leur héritage culturel commun. Parce que la programmation extrême est historiquement marquée par Smalltalk, les fondateurs de cette approche ont culturellement recours aux composants et aux "design patterns" sans même se poser la question. Kent Beck est d’ailleurs l’auteur d’un ouvrage  sur le domaine. La communication y joue un rôle prépondérant en synchronisant les projets, non seulement dans le temps mais aussi dans l'élaboration de composants qui s'enrichissent au bénéfice de la communauté en servant les besoins à court terme.
Dans une logique de projet il faut éviter de se lancer dans des conjectures pour imaginer toutes les utilisations futures d'un composant. Le tacticien ne doit pas s'improviser en statège.

La programmation extrême est en de nombreux points opposé au fordisme en vigeur en

informatique. C'est en effet une certaine volonté empreinte de fordisme d'industrialiser la création informatique qui pousse le spécificateur à découper un projet en morceaux facilement identifiables et définis avec la plus grande minutie. Celui-ci se donne l'illusion d'un contrôle parfait de son projet. C'est pourtant oublier deux choses : le fordisme est parfaitement adapté à la production en série, ce qui n'est pas le cas en informatique et les tâches répétitives sont généralement adaptables dans le temps. Au delà, le fordisme tente de retirer l'initiative aux exécutants. Au contraire, la programmation extrême recommande que les exécutants gardent suffisamment d'autonomie pour redéfinir eux mêmes leur projet à mesure de son avancée. Avec la programmation extrême le spécificateur perd le contrôle a priori de "son" projet. Est-il prêt à céder son pouvoir aux équipes de terrain? Ce n'est de toute façon pas à lui de prendre la décision mais au stratège. Cependant, à l'instar des empereurs de l'Alliance et de leurs généraux en cette fin d'année 1805, le stratège adore les plans magistraux qui font fort effet sur une carte ou sur une présentation électronique. Avec un tel constat, la programmation extrême a-t-elle une chance de s'imposer? La sélection naturelle des entreprises les plus agiles imposera la meilleure stratégie, jusqu'à ce que quelques échecs, réalité de toute l'activité humaine, viennent refroidir l'ardeur des conquérants... Ces derniers se protégeront alors derrière des

 études complètes en se rassurant comme les équipes du projet Edsel de Ford: "nous avons tellement étudié tous les détails, nous avons tout prévu, nous avons tellement investi que nous ne pouvons pas nous tromper".
La programmation extrême est affaire de courage et de détermination, mais aujourd’hui plus que jamais le plus rapide bat le plus lent.

Bien qu'américain, c’est surtout en Suisse que Kent Beck expérimentra la puissance de l'évolution progressive qu’il retraduira dans la programmation extrême. Serait-ce le même air qui avait permis, il y a bientôt deux cents ans, à Henri de Jominy, suisse et membre de l'état major de l'empereur, de produire des analyses analogues dans les ouvrages  de référence sur la stratégie qu'il publiera par la suite?