Trois phases d'application informatique
Le chapitre 5 de Hamming s'ouvre sur une rétrospective : sa série de 30 ans de présentations aux événements de formation des clients d'IBM l'a forcé à comprendre les tendances plutôt que simplement les faits. Préparer la même présentation plusieurs fois l'a obligé à rester en avance sur le domaine, non pas simplement à jour.
Il a identifié trois phases successives dans la façon dont les ordinateurs ont été appliqués :
Phase 1 : Limites matérielles (Chapitre 3). L'informatique primitive était limitée par ce que la machine pouvait faire — la mémoire était rare, les cycles coûtaient cher, la fiabilité était incertaine. Les applications ont été choisies pour s'adapter au matériel.
Phase 2 : Limites logicielles (Chapitre 4). À mesure que le matériel s'améliorait, la programmation devint le goulot d'étranglement. Les applications ont été limitées par ce qui pouvait être codé efficacement.
Phase 3 : Économie & applications (Chapitre 5). À la fin des années 1980, le matériel était assez bon marché & le logiciel assez puissant pour que la question devienne : qu'est-ce que les ordinateurs devraient faire ? L'économie & la capacité organisationnelle déterminaient quelles applications étaient construites.
Cette transition de phase est importante : chaque phase exigeait des compétences complètement différentes des praticiens. Un brillant ingénieur matériel de la Phase 1 qui n'a jamais mis à jour son modèle mental devint inutile en Phase 3.
Applications les plus anciennes
L'informatique a commencé par le calcul astronomique, puis le 'calcul numérique' en physique & ingénierie. Raymond Lull (1235–1315), un théologien espagnol, a construit une machine logique — la première application de l'informatique au raisonnement non numérique. Jonathan Swift l'a satirisée dans Les Voyages de Gulliver (l'île de Laputa). Hamming a tracé cette ligne de Lull à travers la manipulation symbolique jusqu'à ce qui deviendrait : l'apprentissage machine.
La courbe S d'adoption technologique
Chaque technologie majeure suit une trajectoire caractéristique : adoption initiale lente, accélération rapide, saturation. Hamming a nommé ce motif la courbe S.
Phase 1 de toute technologie : démonstration héroïque. Un petit nombre d'enthousiastes démontrent que la technologie fonctionne. Le progrès dépend du génie individuel & de la tolérance à l'inadéquation.
Phase 2 : adoption rapide. La technologie devient assez fiable pour une utilisation générale. L'infrastructure se construit autour. Les normes émergent. Le facteur limitant passe du technique à l'organisationnel.
Phase 3 : saturation. La technologie atteint une pénétration complète de son marché adressable. Les améliorations supplémentaires produisent des rendements décroissants. De nouvelles courbes S commencent pour les technologies successives.
Pour l'informatique : Phase 1 = époque ENIAC (1940–1950), Phase 2 = commercialisation des ordinateurs centraux (1960–1970), Phase 3 = l'informatique personnelle approchant la saturation (1980–1990). Hamming écrivait lors de la transition de la Phase 2 à la Phase 3 pour les ordinateurs centraux, tandis que l'informatique personnelle en était encore à sa Phase 2.
L'équivalent du concept de produit (énoncé pour la première fois au Chapitre 2) s'applique directement ici : en Phase 2, l'informatisation réussie produit un emploi équivalent, pas le même emploi. Les organisations qui ont tenté d'informatiser les flux de travail existants sans les repenser ont souvent échoué ou donné de mauvais résultats.
Se situer sur la courbe S
L'aperçu de la courbe S de Hamming a une implication pratique : les compétences & stratégies qui réussissent en Phase 1 (héroïque, expérimentale, tolérance élevée aux échecs) diffèrent de celles nécessaires en Phase 2 (livraison fiable, conformité aux normes, intégration organisationnelle) et Phase 3 (optimisation, réduction des coûts, consolidation des plates-formes).
Quand les données partagées ne fonctionnent pas
Hamming a raconté une histoire de son époque où il menait un audit de haut niveau du centre informatique de Boeing. La direction de Boeing croyait avoir résolu la conception collaborative : tous les ingénieurs écriraient leur état de conception actuel sur un ruban partagé. Tout le monde lirait à partir de cette source unique de vérité. Les problèmes de coordination disparaîtraient.
Ça n'a pas fonctionné.
La raison : lorsqu'une équipe mène une étude d'optimisation (variant, par exemple, la zone d'aile & le profil pour minimiser la traînée), elle a besoin d'une ligne de base fixe contre laquelle mesurer les changements. Si le ruban partagé se met à jour continuellement avec les changements d'autres équipes, une amélioration qu'une équipe mesure pourrait en réalité refléter le changement de quelqu'un d'autre inséré entre leurs itérations — pas leur propre décision de conception.
La solution que les équipes ont adoptée en pratique : chaque groupe, au début d'une étude d'optimisation, a créé une copie instantanée du ruban actuel. Ils ont utilisé cette copie gelée tout au long de leur étude, ignorant les mises à jour. Ce n'est que lorsqu'ils ont été satisfaits de leur nouveau design qu'ils ont écrit — puis réconcilié avec les changements de tous les autres.
La conclusion de Hamming : vous ne pouvez pas utiliser une base de données en constante évolution pour une étude d'optimisation. L'optimisation nécessite un espace d'état stable ; un état partagé mutable introduit des corrélations fantômes.
Bases de données
Les ordinateurs ont été promus comme solution aux problèmes de données organisationnelles. Hamming était sceptique. Il a cité les systèmes de réservation de compagnies aériennes comme véritablement réussis (le problème de coordination est réel, le modèle de données est simple, & la cohérence est strictement requise). Mais les systèmes d'information de gestion qui promettaient aux managers de dire 'l'état actuel de l'entreprise en temps réel' ont systématiquement sous-livré : les modèles de données étaient trop complexes, la qualité des données trop mauvaise, & l'interprétation trop ambiguë.
Ligne de base stable vs données en direct
L'échec de Boeing illustre un principe général que Hamming impliquait : l'optimisation nécessite une fonction de coût stable évaluée sur un espace d'état fixe. Un état partagé mutable viole l'exigence d'espace d'état fixe.
Ce principe s'étend au-delà du logiciel. Dans tout processus d'optimisation — stratégie commerciale, conception expérimentale, entraînement de modèles — isoler la variable à l'étude nécessite de contrôler toutes les autres.
La reconnaissance de motifs comme nouvelle frontière
En 1993, Hamming a identifié la reconnaissance de motifs comme le principal défi suivant pour l'informatique. Il a distingué deux types :
Reconnaissance classique de motifs : comparer une entrée à un modèle stocké. Détection de visages, OCR (reconnaissance optique de caractères), vérification de signature. Ceux-ci admettent des solutions algorithmiques une fois l'ensemble de modèles défini.
Véritable reconnaissance : un enfant reconnaît 'chaise' dans des milliers de formes, matériaux, tailles & orientations différents, n'en ayant jamais vus la plupart avant. Aucun modèle explicite ne couvre la généralisation. Hamming a traité ceci comme un problème ouvert — l'écart entre la correspondance classique de motifs & la véritable reconnaissance n'était pas une question de plus de données ou de matériel plus rapide. Cela nécessitait des fondations différentes.
Il a encadré ceci en termes d'échec des systèmes experts : les chercheurs pensaient pouvoir extraire les règles de décision des experts & les encoder dans des programmes. Les systèmes experts ont fonctionné dans des domaines étroits mais ont échoué dans les domaines complexes, en partie parce que les experts humains utilisent des motifs qu'ils ne peuvent pas articuler. La bibliothèque de motifs inconscients construite au fil des années de pratique ne peut pas être extraite par des entretiens.
La prédiction de Hamming (1993) : la véritable reconnaissance de motifs nécessiterait des approches informatiques fondamentalement différentes. Il a fait un geste vers les réseaux de neurones mais était prudent — non convaincu que les réseaux de neurones de l'époque colmateraient l'écart.
Donner la même présentation pendant 30 ans
Hamming a décrit une pratique qui lui a donné plus de rendement que presque tout autre chose dans sa vie professionnelle : donner la même présentation plusieurs fois.
Il a été invité à parler aux événements de formation des clients d'IBM vers 1960. Il a choisi de donner une présentation sur L'histoire de l'informatique jusqu'à l'an 2000 — un sujet sur lequel il était véritablement incertain, ce qui l'a forcé à développer des points de vue réels. Il a donné des variantes de cette présentation deux ou trois fois par an pendant 30 ans.
Les avantages qu'il a identifiés :
Rester actuel : donner la même présentation plusieurs fois l'a forcé à la mettre à jour régulièrement. Il ne pouvait pas donner une présentation périmée sans s'embarrasser devant des publics qui suivaient le domaine.
Reconnaissance des tendances : le processus de mise à jour l'a forcé à chercher des tendances, pas juste des événements. Qu'est-ce qui a changé au cours de la dernière année, et dans quelle direction ? La mise à jour répétée nécessitait un modèle du domaine, pas juste un catalogue de faits.
Compétences en parlor en public : la pratique a réduit la peur & amélioré la livraison. Il a cessé d'avoir peur de donner des présentations ; il est devenu un orateur poli par la répétition plutôt que par le talent.
Réseau : un sujet cohérent a construit une réputation. Les gens l'associaient aux tendances informatiques. Les invitations se sont multipliées.
Son observation : il aurait pu acquérir cette pratique par chance — mais il a fait la chance en cherchant activement des opportunités de parler, puis en développant la discipline de les utiliser systématiquement.
Pratique délibérée & capital de carrière
La présentation de 30 ans de Hamming était une instance de pratique délibérée appliquée au travail intellectuel : un exercice systématique et répété avec des cycles de rétroaction qui ont construit des compétences composées au fil du temps.
La structure : (1) s'engager sur un sujet à la limite de votre connaissance ; (2) donner une présentation, ce qui vous force à la connaître ; (3) recevoir des commentaires (réaction du public, questions auxquelles vous ne pouviez pas répondre) ; (4) mettre à jour la présentation ; (5) répéter.
Chaque cycle ajoute à un modèle. Chaque mise à jour force le contact avec de nouvelles données. Chaque question du public révèle un écart. Sur 30 ans, le modèle devient profond.
Connecter le matériel, les logiciels & les applications
Les chapitres 3, 4, & 5 forment une progression. Hamming a construit l'argument sur trois cours :
Chapitre 3 (Matériel) : les limites physiques limitent ce que les machines peuvent faire. Trois lois — taille moléculaire, vitesse de la lumière, chaleur — fixent des plafonds qu'aucune ingénierie ne peut enlever.
Chapitre 4 (Logiciel) : les limites humaines limitent ce que les programmes peuvent faire. Les langages conçus pour l'élégance logique échouent ; les langages conçus pour la psychologie humaine survivent. Les couches d'abstraction s'accumulent, chacune résolvant la douleur de la couche précédente.
Chapitre 5 (Applications) : les limites économiques & organisationnelles limitent ce qui est construit. La technologie suit les courbes S. L'état partagé mutable casse l'optimisation. La reconnaissance de motifs reste un défi ouvert.
Le thème unificateur : les limites se déplacent. Le praticien qui met à jour son modèle de ce que la contrainte contraignante actuelle — et positionne ses compétences en conséquence — surpasse systématiquement celui qui optimise pour les contraintes d'hier.
La leçon de carrière de Hamming de la présentation de 30 ans : donner la même présentation plusieurs fois l'a forcé à comprendre les tendances. Le mécanisme n'était pas la présentation elle-même mais le cycle de préparation : qu'est-ce qui a changé, dans quelle direction, et pourquoi ? La préparation répétée a construit un modèle que la simple lecture ne pouvait pas.
Quelle est la contrainte contraignante actuelle ?
Dans le cadre de Hamming, chaque époque a une contrainte contraignante : la limite qui, si supprimée, accélérerait le plus les progrès. Dans les années 1940 : vitesse matérielle. Dans les années 1970 : capacité logicielle. Dans les années 1990 : capacité économique & organisationnelle.