Proprement codeur

Code de conduite
pour développeurs professionnels

Robert C. Martin

Pearson France a apporté le plus grand soin à la réalisation de ce livre afin de vous fournir une information complète et fiable. Cependant, Pearson France n’assume de responsabilités, ni pour son utilisation, ni pour les contrefaçons de brevets ou atteintes aux droits de tierces personnes qui pourraient résulter de cette utilisation.

Les exemples ou les programmes présents dans cet ouvrage sont fournis pour illustrer les descriptions théoriques. Ils ne sont en aucun cas destinés à une utilisation commerciale ou professionnelle. Pearson France ne pourra en aucun cas être tenu pour responsable des préjudices ou dommages de quelque nature que ce soit pouvant résulter de l’utilisation de ces exemples ou programmes.

Tous les noms de produits ou marques cités dans ce livre sont des marques déposées par leurs propriétaires respectifs.

Le présent ouvrage est la traduction adaptée de CLEAN CODER: A CODE OF CONDUCT FOR PROFESSIONAL PROGRAMMERS, 1st Edition by ROBERT MARTIN, publié par Pearson Education Inc./ Pearson, Copyright © 2011 Pearson Education Inc.

Authorized translation from the English language edition, entitled CLEAN CODER: A CODE OF CONDUCT FOR PROFESSIONAL PROGRAMMERS, 1st Edition by ROBERT MARTIN, published by Pearson Education, Inc, publishing as Pearson, Copyright © 2011, Pearson.

FRENCH language edition published by PEARSON FRANCE, Copyright © 2021.

Publié par Pearson France

Titre original : Clean Coder - A Code of Conduct for Professional Programmers

2 rue Jean Lantier

75001 Paris

Traduction :

Olivier Engler

www.pearson.fr

Couverture :

Carl Brand

Mise en pages :

INASENZ

Dépôt légal :

février 2022

ISBN : 978-2-3260-5980-1

ISBN original : 978-0-13-708107-3

Copyright © 2022 Pearson France

Copyright © 2011 Pearson Education, Inc.

Tous droits réservés

All rights reserved

Aucune représentation ou reproduction, même partielle, autre que celles prévues à l’article L. 122-5 2˚ et 3˚ a) du code de la propriété intellectuelle ne peut être faite sans l’autorisation expresse de Pearson France ou, le cas échéant, sans le respect des modalités prévues à l’article L. 122-10 dudit code.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.

Dédicace

Entre 1986 et 2000, j’ai travaillé en étroite collaboration avec mon collègue Jim Newkirk, au sein de la société Teradyne. Nous avions en commun la passion de programmer et de produire du code source propre. Nous enchaînions nuits et week-ends à expérimenter différents styles de conception et de programmation. Nous ne cessions de réfléchir à des projets commercialisables et avons fini par fonder ensemble la société Object Mentor. J’ai beaucoup appris de Jim tout en combinant mes idées aux siennes, mais c’est d’abord son attitude éthique dans le travail que j’ai tenté d’adopter à mon tour. Jim est un vrai professionnel. Je suis fier d’avoir pu travailler avec lui et de pouvoir l’appeler mon ami.

Table des matières

Dédicace

Avant-propos

Préface

À propos de ce livre

Bibliographie

Remerciements

À propos de l’auteur

Image de couverture

Introduction incontournable

Chapitre 1 : Professionnalisme

Droits et devoirs

Prendre ses responsabilités

D’abord, ne pas nuire

Ne pas nuire à la fonction

Ne pas nuire à la structure

Éthique professionnelle

Connaissez vos classiques

Apprentissage continu

Bibliographie

Chapitre 2 : Savoir dire non

Rôles opposés

Chercher les raisons ou pas ?

De l’importance des enjeux

Agir dans un esprit d’équipe

Essayer ?

Agressivité passive

Le coût du oui

Peut-on livrer du bon code (par John Blanco) ?

Le bon code est-il impossible ?

Chapitre 3 : Savoir dire oui

Le langage de l’engagement (par Roy Osherove)

Apprendre à dire oui

Essayer, ce n’est pas l’adopter

Conclusion

Chapitre 4 : Coder

Préparation

Le codage de fin de nuit nuit

Code et problèmes

L’état de grâce et la zone du flow

Accompagnement musical

L’angoisse de la feuille blanche

Inspiration créative

Débogage

Temps passé au débogage

Prendre soin de soi

Savoir faire une pause

Le chemin du retour

La douche régénérante

Être en retard

Espoirs et vœux pieux

Courir pour mal finir

Heures supplémentaires

Livraisons frauduleuses

Un « fini » clairement indéfini

Donner et recevoir de l’aide

Aider les autres

Recevoir de l’aide

Monitorat

Bibliographie

Chapitre 5 : Développement dirigé par les tests ou TDD

Le verdict est tombé

Les trois lois de TDD

Une galerie de bénéfices

Ce que TDD n’est pas

Bibliographie

Chapitre 6 : Entraînement

Entraînement du développeur : un peu d’histoire

À la puissance 22 !

Le temps de cycle

Le dojo du codage

Kata

Waza

Randori

Extension du domaine de l’expérience

Conclusion

Bibliographie

Chapitre 7 : Tests d’acceptation et recette

Communication et exigences

Précision prématurée

Ambiguïté tardive

Tests d’acceptation

La définition d’achèvement, « definition of done »

Communication

Automatisation

Supplément de travail

Rédaction des tests : par qui et quand ?

Rôle du développeur

Négociation et agression passive

Tests d’acceptation et tests unitaires

Interface graphique et autres complications

Intégration continue

Arrêtez tout !

Conclusion

Chapitre 8 : Stratégies de test

L’assurance qualité doit être bredouille

L’assurance qualité fait partie de l’équipe

La pyramide de l’automatisation des tests

Tests unitaires

Test des composants

Tests d’intégration

Tests système

Tests manuels d’exploration

Conclusion

Bibliographie

Chapitre 9 : Gestion du temps

Réunions

Décliner l’invitation

Écourter sa présence

Avoir un ordre du jour et un objectif

Les réunions debout (stand-up)

Les réunions de planification d’itération

La rétrospective d’itération et la démonstration

Disputes et désaccords

Mana et énergie de concentration

Sommeil

Caféine

Rechargement de mana

Concentration physique

Inspiration et expiration créative

Blocs de temps et chronotomates

Stratégies d’évitement

Inversion de priorités

Impasses et marche arrière

Marécages, bourbiers et autres bazars

Conclusion

Chapitre 10 : Estimations

Qu’est-ce qu’une estimation ?

Un engagement

Une hypothèse

Engagement implicite

La technique PERT

Techniques d’estimation des tâches

Estimation de Delphes à large bande

Les doigts de vote

Le planning poker

Estimation d’affinités

Estimation trivariée

La loi des grands nombres

Conclusion

Bibliographie

Chapitre 11 : Pression

Éviter la pression

Engagement

Rester propre

Discipline en temps de crise

Gérer la pression

Ne paniquez pas

Communiquez

Appuyez-vous sur vos règles

Demandez de l’aide

Conclusion

Chapitre 12 : Collaboration et coopération

Programmeurs et autres humains

Les programmeurs et les employeurs

Les programmeurs contre les programmeurs

Frottement de cervelets

Conclusion

Chapitre 13 : Équipes et projets

Faire prendre l’émulsion

Une équipe soudée

Comment gérer tout cela ?

Le dilemme du maître d’ouvrage ou du Project Owner

Conclusion

Bibliographie

Chapitre 14 : Guides, apprentis et artisans

Des diplômes aux multiples lacunes ?

Guides et moniteurs

Mon premier ordinateur : le Digi-Comp

L’ECP-18 du lycée

Formations non conventionnelles

Souffrir pour apprendre

Apprentissage

Apprentissage logiciel

Maître programmeur

Compagnon programmeur

Apprenti et stagiaire

Le principe de réalité

Artisanat

Convaincre les personnes

Conclusion

Annexe : Outillage

Une sélection d’outils

Contrôle de version du code source

Système de contrôle du source « d’entreprise »

Verrouillage pessimiste ou optimiste

CVS/SDN

Arbre et branches

git

Éditeur et environnement de développement EDI

L’éditeur vi

L’éditeur Emacs

Eclipse et IntelliJ

TextMate

Suivi des problèmes

Nombre de bogues actifs

Construction continue

Outils de tests unitaires

Outils de test de composants

La définition d’achèvement (definition of done)

FitNesse

Autres outils de test de composants

Outil de tests d’intégration

Outils de modélisation UML/MDA

Les détails qui tuent

Rien de nouveau sous le soleil

Conclusion

Index

Avant-propos

par Matthew Heusser (naturaliste des processus logiciels)

Puisque vous avez ouvert ce livre, je suppose que vous êtes un professionnel du logiciel. J’en suis un également. Et puisque je peux profiter de votre attention, laissez-moi d’abord vous expliquer pourquoi je considère que ce livre est remarquable.

Tout a commencé dans un petit village paisible… Éteignez les lumières, la séance commence.

Voici quelques années, je travaillais dans une entreprise de taille intermédiaire qui vendait des produits soumis à d’importantes contraintes réglementaires. Des conditions de travail classique : un bâtiment de trois étages, tous dans le même espace ouvert, sauf les chefs et la direction qui disposaient chacun d’un bureau fermé. Il fallait s’y prendre au moins une semaine à l’avance pour réussir à organiser une réunion avec l’ensemble du personnel.

L’entreprise comptait un bon nombre de concurrents. Un jour, le gouvernement a autorisé la commercialisation d’un nouveau produit.

Une nouvelle catégorie de clients s’offrait à nous ; il ne nous restait plus qu’à les persuader d’acheter notre produit. Cela supposait de soumettre des formulaires au gouvernement avant une date limite, de réussir un audit de conformité avant une autre date et de lancer le produit sur le marché avant une troisième date limite.

La direction de l’entreprise ne cessait de nous rappeler qu’il fallait absolument respecter ces dates. Un seul retard, et le gouvernement nous bannissait de ce marché pendant un an. Il est évident que si les clients ne pouvaient pas commander dès le premier jour, ils se tourneraient vers un concurrent. Nous serions alors éliminés de la compétition.

Dans ce genre de contexte, certaines personnes se lamentent alors que d’autres rappellent que c’est dans l’adversité qu’on fait des prouesses.

J’étais à l’époque responsable technique, après avoir été développeur. La mission était de faire en sorte que le site Web soit accessible le jour du lancement pour que les clients potentiels puissent télécharger des brochures et s’inscrire à l’aide de formulaires. Mon partenaire dans cette aventure était le responsable commercial du projet, que j’appellerai Joe. Lui prenait en charge les problèmes de vente, de marketing et tout ce qui n’était pas technique. C’est lui qui rappelait à qui voulait l’entendre que, sous pression, on pouvait faire des prouesses.

Ceux qui ont travaillé en entreprise connaissent certainement ces comportements malsains consistant à chercher un coupable en cas de problème pour se protéger. C’est totalement naturel. Dans cette société, Joe et moi incarnions une solution intéressante à ce genre de problème.

Notre travail était de réussir à faire ce qui était prévu, un peu comme Batman et Robin. Je rencontrais l’équipe technique tous les jours dans un coin. Nous mettions à jour le planning, cherchant le nouveau chemin critique et supprimant tous les obstacles qui se présentaient sur ce chemin. Si quelqu’un avait besoin d’un logiciel, nous l’autorisions à l’acheter. Que quelqu’un ait envie de configurer le pare-feu sur-le-champ, mais prétende que c’était justement l’heure de sa pause repas, nous l’autorisions à aller déjeuner. Si quelqu’un se sentait capable de résoudre notre problème de configuration, mais avait hélas d’autres priorités, Joe et moi allions voir son supérieur afin de trouver une solution.

Puis nous parlions au manager.

Puis nous montions chez le grand directeur.

Nous faisions avancer les choses.

Ce serait exagéré que de dire que nous allions jusqu’à renverser les chaises et à éclater de colère dans les couloirs. Toutefois, il est vrai que nous utilisions tous les stratagèmes imaginables pour progresser, sans oublier d’en inventer quelques-uns, et tout cela dans un esprit éthique dont je reste fier aujourd’hui.

Je me considérais comme membre d’une équipe. C’est pourquoi je n’hésitais pas à donner un coup de main en écrivant une instruction SQL ou deux ou à travailler en binôme pour terminer un bloc de code. En ce temps-là, je considérais Joe comme mon égal, un membre de l’équipe.

Mais j’avais fini par réaliser que Joe ne partageait pas ma vision. Ce fut un jour très triste.

C’était un vendredi, et il était 13 heures. Le site Web devait être ouvert le lundi matin suivant.

Nous avions terminé. FINI. Tous les systèmes étaient prêts. J’avais réuni les équipes techniques pour une dernière mêlée finale, nous étions prêts à basculer l’interrupteur. Nous avions aussi invité les gens du marketing, les commerciaux et le Product Owner.

Nous étions fiers de nous, et c’était un grand moment.

C’est à ce moment précis que Joe avait fait son apparition.

Il avait bredouillé un truc dans le style : « Mauvaise nouvelle. Le département juridique n’a pas terminé les formulaires d’inscription et nous ne pouvons donc pas ouvrir le site. »

Une péripétie de plus, me disais-je. Nous avions été retardés à de multiples reprises tout au long du projet et avions à chaque fois appliqué la fameuse stratégie « Batman et Robin ». J’étais donc prêt et ai répondu quelque chose dans le style : « Ok, collègues, on n’a qu’à appliquer une fois de plus notre technique gagnante. Le département juridique, c’est bien au troisième étage ? »

C’est à ce moment que les choses ont tourné au vinaigre.

Au lieu d’accepter ma proposition, Joe s’est écrié : « De quoi parles-tu, Matt ? »

« Tu sais bien, lui ai-je répondu. Notre tactique habituelle. On parle bien de quatre fichiers PDF ? Ils sont prêts ? Il ne reste qu’à les faire valider par le département juridique ? Montons nous poster devant leur bureau en faisant les gros yeux afin de boucler cette dernière action ! »

Mais Joe n’avait pas été emballé par ma proposition et s’était contenté de répondre : « Non, on ouvrira le site Web un peu plus tard que prévu la semaine prochaine. Ce n’est pas si grave. »

Vous imaginez aisément la suite de la conversation. Cela ressemblait un peu à ceci :

Moi. – Mais pourquoi ? Ils peuvent tout valider en quelques heures.

Joe. – Cela pourrait prendre plus de temps.

Moi. – Mais on a tout le week-end ! Ils ont le temps. On y va ?

Joe. – Matt, ce sont des professionnels. Nous ne pouvons pas les regarder de haut et leur demander de sacrifier leur vie privée pour notre petit projet.

Moi. – (Après une pause.) Je… Que crois-tu que nous avons fait depuis plusieurs mois avec l’équipe technique ?

Joe. – Oui, mais eux sont des professionnels.

Pause.

Longue inspiration.

Qu’est-ce que… Joe…vient… juste… de dire ?

À l’époque, j’étais persuadé que l’équipe technique était constituée de professionnels dans le meilleur sens du terme.

Rétrospectivement, je n’en suis plus si certain.

Adoptons un autre point de vue sur la fameuse technique Batman et Robin. Je pensais que j’encourageais toute l’équipe à donner le meilleur d’elle-même. Je pensais également que Joe voyait les choses comme moi, comme une sorte de jeu avec l’équipe technique comme adversaire. Quand on y pense, pourquoi fallait-il renverser les chaises et inonder les gens d’encouragements ?

N’aurait-il pas mieux valu demander à l’équipe d’annoncer quand elle aurait fini, obtenir une réponse ferme, se baser sur cette réponse, mais sans en être totalement dépendant ?

En tant que professionnels, nous aurions dû fonctionner ainsi, mais nous ne pouvions pas. Joe n’avait pas confiance dans nos annonces et préférait micromanager l’équipe. Pourtant, simultanément, et pour une raison inconnue, il faisait confiance à l’équipe juridique et ne cherchait pas du tout à les micromanager.

Comment cela est-il possible ?

L’équipe juridique avait sans doute fait preuve d’un professionnalisme que l’équipe technique n’avait pas démontré.

Cet autre groupe avait donc convaincu Joe qu’il n’avait pas besoin d’un baby-sitter, ni de se livrer à un jeu de rôles et qu’il devait être considéré comme un partenaire à respecter.

Je ne crois pas que cette différence de traitement soit liée à de jolis diplômes accrochés au mur ou à quelques années de formation complémentaire, même si ces années dans le supérieur auraient sans doute apporté à notre équipe des techniques de comportement bienvenues.

Depuis ce jour lointain, je continue à me demander de quelle façon notre profession technique devrait évoluer pour être considérée comme véritablement professionnelle.

Bien sûr, j’ai dégagé quelques pistes. J’ai tenu un blog, j’ai beaucoup lu, j’ai réussi à améliorer ma situation professionnelle et à aider quelques personnes. Pourtant, je n’ai jamais lu un livre abordant ce problème de façon explicite.

Un jour pourtant, sans crier gare, j’ai reçu une proposition pour réviser le manuscrit d’un livre. C’est celui que vous tenez entre vos mains.

Vous découvrirez dans ce livre pas à pas comment vous présenter et comment interagir en tant que professionnel. Ce ne sont pas des astuces, ni des techniques pour valoriser vos diplômes. Le livre montre ce que vous pouvez faire et comment faire.

Certains exemples sont à prendre littéralement au pied de la lettre.

D’autres recèlent des réponses, des contre-arguments, des clarifications, ainsi que des conseils pour savoir comment réagir lorsque l’interlocuteur cherche tout simplement à vous ignorer.

Mais tiens, voilà Joe qui revient, côté jardin. Nous travaillons maintenant Joe et moi dans une mégaentreprise et sommes chargés de finaliser un projet de conversion d’un énorme site Web.

Cette fois-ci, imaginons que les choses se déroulent un peu différemment.

Au lieu d’esquiver ses engagements, l’équipe technique s’engage et atteint ses objectifs. Au lieu d’esquiver les estimations ou de laisser quelqu’un d’autre planifier à sa place pour se plaindre ensuite, l’équipe technique s’auto-organise et s’engage réellement.

Supposons que l’équipe soit en plein travail. Quand elle se trouve bloquée par l’équipe d’exploitation, elle téléphone à l’administrateur système qui vient immédiatement l’aider.

Quand Joe s’inquiète de l’état d’avancement de la résolution du ticket de problème 14321, il n’a plus à s’inquiéter ; il peut voir immédiatement que l’administrateur travaille déjà sur le sujet au lieu de surfer sur le Web. Dorénavant, les estimations qu’il reçoit semblent cohérentes. Il n’a plus l’impression que le projet n’est prioritaire qu’entre les deux plages horaires du déjeuner et de la gestion des courriels personnels. Les réévaluations du planning ne sont pas faites en déclarant « On va essayer d’y parvenir » mais en répondant « Nous nous engageons ; vous pouvez mettre à jour votre planning à partir des dates que nous vous indiquons ».

J’imagine que, sur ces bases, Joe commencerait à se dire que l’équipe technique se comporte de façon professionnelle et il aurait raison.

Quelles sont les étapes qui permettent de passer du statut de simple exécutant à celui de professionnel ? Vous les trouverez dans la suite de ce livre.

Bienvenue dans la prochaine étape de votre carrière. J’imagine que vous allez beaucoup apprécier.

Préface

Le 28 janvier 1986 à 11 h 39 heure locale de la Floride, la navette Challenger s’est disloquée en plein ciel 73 secondes après son décollage et à une altitude d’environ 15 km. Il s’est avéré que la catastrophe avait été provoquée par une fuite entre deux segments de l’enveloppe du propulseur d’appoint à poudre droit, le SRB (Solid Rocket Booster). Sept courageux astronomes ont péri, parmi lesquels l’institutrice Christa McAuliffe. Je ne pourrai jamais oublier l’expression du visage de sa mère qui regardait en direct le décollage sur la base de Cap Canaveral.

Ce qui a provoqué la catastrophe ? Une fuite de gaz brûlant entre deux segments de l’enveloppe du propulseur d’appoint droit. Les flammes s’étaient rapidement répandues jusqu’à rejoindre le réservoir liquide principal. La partie inférieure de ce gros réservoir contenait de l’hydrogène liquide, qui s’est enflammé et qui a propulsé le réservoir d’hydrogène contre le réservoir d’oxygène placé au-dessus de lui. En même temps, le propulseur d’appoint rompait sa fixation arrière, ce qui l’a fait pivoter autour de la fixation avant et le nez du propulseur a percé le réservoir d’oxygène liquide. Ces différentes forces non parallèles à la trajectoire ont provoqué la mise en travers de l’ensemble à une vitesse supérieure à 1 500 km/h. La structure ne pouvait pas résister à de telles forces aérodynamiques.

La jonction entre deux segments de l’enveloppe du propulseur comportait deux joints toriques (des anneaux) en caoutchouc pour assurer l’étanchéité. Lorsque les segments étaient boulonnés pour constituer le propulseur, les joints toriques étaient mis en compression, ce qui assurait une étanchéité parfaite contre les gaz d’éjection.

Au cours de la nuit qui a précédé le lancement, la température sur le pas de tir était descendue jusqu’à –8 °C, alors que la température d’utilisation minimale des joints toriques était obligatoirement supérieure à zéro. La température la plus froide connue au cours d’un lancement précédent était de 10° supérieure à celle de ce jour fatidique. Les joints toriques étaient devenus trop rigides pour empêcher les gaz d’éjection de passer. Lors de l’allumage des deux propulseurs, une onde de pression a été provoquée par l’accumulation des gaz d’éjection. Les segments d’enveloppe du propulseur se sont légèrement écartés, ce qui a réduit la force de compression des joints. Mais ces joints avaient perdu leur souplesse, ce qui les a empêchés de jouer leur rôle. C’est ainsi que des gaz d’éjection brûlants ont pu se glisser, détruisant au passage les joints toriques sur quasiment un quart de cercle de l’enveloppe.

Les propulseurs à poudre de la navette étaient réalisés par la société Morton Thiokol. Leurs ingénieurs savaient que les joints toriques étaient défectueux. Ils avaient averti de ce problème les responsables de Morton et de la NASA depuis plus de sept ans. En effet, les joints toriques utilisés lors des lancements précédents avaient déjà été endommagés, mais pas suffisamment pour entraîner une catastrophe. Ceux des lancements les plus froids étaient ceux qui avaient le plus souffert. Les ingénieurs avaient déjà étudié une solution pour résoudre ce problème, mais cette dernière avait été reportée sans cesse et n’avait donc pas encore été mise en place.

Les ingénieurs se doutaient que les joints toriques perdaient de leur élasticité dans le froid. Ils savaient que la température lors du lancement de Challenger serait inférieure à celle de tous les lancements précédents, et surtout inférieure à une limite technique. Autrement dit, les ingénieurs savaient que le risque était trop élevé. Ils avaient donc agi sur la base de ces connaissances en rédigeant des bulletins d’avertissement à l’encre rouge. Ils avaient demandé à Thiokol et aux responsables de la NASA de ne surtout pas autoriser le lancement. Une réunion juste avant le lancement avait duré 11 heures, et

les ingénieurs avaient communiqué à nouveau toutes les données dont ils disposaient. Ils s’étaient mis en colère, avaient protesté, avaient essayé de convaincre. Au final, les managers avaient ignoré leurs mises en garde répétées.

L’heure du lancement approchant, certains ingénieurs avaient carrément refusé de visionner l’événement, tant ils redoutaient une explosion sur le pas de tir. Mais dès que Challenger a commencé à se hisser avec grâce dans le ciel bleu et froid, leur réticence les abandonna. Quelques secondes avant la destruction, constatant que la fusée avait franchi le mur du son, l’un d’eux s’était réjoui en s’exclamant : « On l’a échappé belle ! »

En dépit de tous les bulletins, de toutes les protestations et de toute la pression des ingénieurs, des managers avaient considéré qu’ils savaient mieux que les autres ce qu’il convenait de faire. Ils avaient considéré que les ingénieurs exagéraient. Ils ne faisaient pas confiance aux données, ni aux conclusions des ingénieurs. Ils avaient autorisé le lancement parce que la pression tant financière que politique était intense. En fait, les managers espéraient que tout allait bien se passer.

Ces managers ne se sont pas seulement comportés de manière déraisonnable, mais comme de vrais criminels. Les vies de sept personnes et les espoirs de toute une génération qui s’apprêtait à participer à l’aventure des voyages spatiaux avaient été pulvérisés parce que des managers avaient donné la priorité à leurs espoirs et à leur intuition en négligeant la parole de leurs propres experts. Ils avaient pris une décision qu’ils n’avaient pas le droit de prendre. Ils avaient outrepassé l’autorité des gens qui savaient : les ingénieurs.

Mais ces ingénieurs sont-ils pour autant sans reproche ? Ils ont certainement fait ce qu’ils devaient faire en informant les managers et en se battant pour faire accepter leur vision des choses. Ils avaient utilisé tous les canaux de communication disponibles et tous les protocoles en vigueur. Ils avaient fait ce qu’ils pouvaient, en restant dans le cadre du système, mais cela n’avait pas suffi. Nous pouvons donc en conclure que les ingénieurs n’ont rien à se reprocher.

Pourtant, je me demande si après toutes ces années ces ingénieurs dorment tranquilles, ou s’ils sont encore tourmentés par l’image de la mère de Christa McAuliffe. Peut-être certains regrettent-ils de ne pas avoir rendu publiques leurs craintes sur les chaînes de télévision d’information continue ?

À propos de ce livre

Ce livre est entièrement consacré à la professionnalisation du métier de développeur de logiciels. Il réunit une foule de conseils pratiques dans le but de répondre à quelques questions :

Qu’est-ce qu’un professionnel du logiciel ?

Comment un professionnel doit-il se comporter ?

Comment un professionnel doit-il gérer les conflits, les plannings trop serrés et les donneurs d’ordres déraisonnables ?

Quand et comment le professionnel doit-il dire non ?

Comment un professionnel doit-il gérer la pression ?

Accepter toute la responsabilité qui incombe à un artisan ou à un ingénieur suppose de travailler bien et proprement, de communiquer clairement et de procéder à des estimations honnêtes et fiables. Cela suppose de gérer votre temps et d’affronter les décisions importantes et difficiles.

Cette responsabilité en entraîne une autre qui peut s’avérer effrayante : en tant qu’ingénieur, vous possédez une profondeur de connaissances à propos de vos systèmes et de vos projets qu’il est impossible à un manager d’acquérir. Cette connaissance unique vous rend responsable d’agir en conséquence.

Bibliographie

McConnell M., Challenger: A Major Malfunction, Simon & Schuster, 1987.

« Accident de la navette spatiale Challenger », https://fr.wikipedia.org/wiki/Accident_de_la_navette_spatiale_Challenger

Remerciements

Ma carrière est une suite de collaborations et d’aventures. J’ai eu bien des rêves et des désirs personnels, et il me semble que j’ai toujours trouvé quelqu’un pour les partager. Je me sens un peu comme un Sith de Star Wars, allant toujours par deux.

La première collaboration que je peux considérer comme professionnelle avait concerné un certain John Marchese. J’avais alors 13 ans. Nous avions décidé de construire des ordinateurs ensemble. J’étais le cerveau et lui les bras. Je lui montrais où il fallait souder un câble et lui le soudait. Je déterminais où il fallait monter un relais et lui le montait. Nous nous amusions follement des heures durant. Nous étions parvenus à construire

un certain nombre d’objets d’allure impressionnante bourrés de relais, de boutons, de témoins lumineux. Nous avions même ajouté un téléscripteur ! Bien sûr, aucun de ces appareils ne fonctionnait, mais ils étaient impressionnants à voir et nous avions mis tout notre cœur à les construire. Cher John, merci encore !

Lors de ma première année au lycée, j’ai rencontré Tim Conrad en cours d’allemand. Tim était habile. Nous avions décidé une fois encore de construire des ordinateurs, mais lui était le cerveau et moi l’exécutant. Il m’avait appris l’électronique et m’avait initié aux mini-ordinateurs PDP-8. Nous avions construit une calculatrice binaire sur 18 bits uniquement à partir de composants élémentaires. La machine savait faire les quatre opérations arithmétiques. Nous avions dû y consacrer tous les week-ends et toutes les vacances scolaires pendant un an. Nous étions hypermotivés, et le résultat fut tout à fait concluant. Cher Tim, merci !

C’est avec Tim que j’ai appris à écrire un programme informatique. Ce n’était pas facile en 1968, mais nous y étions parvenus. Nous avions trouvé les livres qui décrivaient le langage assembleur du PDP-8, le Fortran, le Cobol, le PL/1 et autres langages. Nous avions dévoré ces livres. Nous avions écrit des programmes que nous savions ne jamais pouvoir exécuter parce que nous n’avions pas accès à un ordinateur approprié. Nous les avions néanmoins écrits pour l’amour du travail bien fait.

Lorsque j’étais en première, notre lycée avait organisé un cursus de science informatique. Pour les travaux pratiques, ils avaient prévu un téléscripteur SRT-33 relié à un modem téléphonique à 110 bauds. Nous disposions d’un compte sur un gros ordinateur en temps partagé Univac 1108 installé dans l’IUT de l’Illinois. Tim et moi étions immédiatement devenus les opérateurs attitrés pour travailler sur cette machine. Plus personne ne pouvait y toucher, ni même s’en approcher.

Pour établir une connexion à l’aide du modem, il fallait composer un numéro de téléphone. Dès que vous entendiez le son strident d’attente de connexion, il suffisait d’appuyer sur le bouton Orig du télétype de sorte que l’autre modem émette le même son strident. Il n’y avait alors plus qu’à reposer le combiné. La connexion était établie.

Il y avait un cadenas sur le téléphone et les enseignants en gardaient la clé. Aucun problème, nous avions vite découvert que vous pouviez composer un numéro (à partir de n’importe quel téléphone) en simulant les impulsions avec le doigt sur un contact. Comme j’étais batteur, j’avais d’assez bons réflexes et une bonne synchronisation de mouvements, ce qui me permettait de composer le numéro alors que le verrou était en place, et ce, en moins de 10 secondes.

Le laboratoire informatique disposait de deux téléscripteurs : un qui était en service et l’autre hors ligne. Les deux servaient aux étudiants pour écrire les programmes. Au fil de la saisie, le rouleau de bande de papier perforé retranscrivait les frappes de touche. Les étudiants utilisaient le langage IITran, un langage interprété étonnamment puissant, puis déposaient leurs rouleaux de papier perforé dans un panier à côté des téléscripteurs.

Après les cours, Tim et moi nous connections (selon ma méthode spéciale), puis chargions les bandes perforées dans le système de traitement par lots IITran avant de raccrocher. Cela prenait un certain temps, à la vitesse de 10 caractères par seconde. Autrement dit, une heure plus tard, nous pouvions nous reconnecter pour récupérer les résultats, toujours à 10 caractères par seconde. Le téléscripteur ne créait pas de séparation physique entre la fin du listing d’un étudiant et le début du suivant. Tout était imprimé à la suite. Il nous restait donc à couper les différents listings, puis à accrocher chacun d’eux avec un trombone à la bande de données d’entrée, et enfin à tout déposer dans le panier de résultats.

Tim et moi étions vraiment devenus des experts dans ce processus. Lorsque nous étions dans la salle, même les enseignants nous laissaient tranquilles. Après tout, nous faisions leur travail, ils s’en étaient bien rendu compte. Pour autant, nous n’avions jamais bénéficié d’une autorisation quelconque pour nous en acquitter. Jamais ils ne nous avaient confié la clé du cadenas du téléphone. Nous arrivions, ils sortaient, et nous laissaient toute liberté. Je tiens donc à remercier mes professeurs de mathématiques McDermit, Fogel et Robien.

Une fois que nous avions terminé de traiter les demandes des étudiants, nous pouvions jouer. Nous avions écrit des dizaines de programmes qui faisaient des choses complètement folles. Des programmes qui traçaient des cercles et des paraboles avec des lettres de l’alphabet sur un téléscripteur. Des programmes qui généraient des mots au hasard. Des programmes qui savaient calculer la factorielle de 50. Nous avions passé des heures à écrire de tels programmes et à les faire fonctionner.

Deux ans plus tard, Tim, moi et notre collègue Richard Lloyd avons été tous les trois embauchés par la société ASC Tabulating de Lake Bluff dans l’Illinois. Tim et moi n’avions que 18 ans. Nous avions décidé que poursuivre nos études serait une perte de temps et qu’il nous fallait lancer notre carrière au plus tôt. C’est ainsi que nous avions rencontré Bill Hohri, Frank Ryder, Big Jim Carlin et John Miller qui avaient choisi de montrer à quelques débutants ce qu’était vraiment la programmation professionnelle. L’expérience n’avait été ni trop bonne, ni trop mauvaise ; en tout cas, elle nous avait beaucoup appris. Je tiens à remercier ces personnes, et notamment Richard qui avait organisé et conduit l’essentiel du processus.

Après avoir donné ma démission sans savoir au juste pourquoi, à l’âge de 20 ans, j’avais fait une tentative en tant que réparateur de tondeuses pour mon beau-frère. Je me débrouillais tellement mal qu’il n’avait pas tardé à me renvoyer. Je te remercie, Wes !

Environ un an plus tard, j’étais embauché chez un réparateur de moteurs pour hors-bord, Outboard Marine Corp. Je m’étais marié et j’allais avoir un enfant. Il m’avait néanmoins licencié. Merci encore, John, Ralph et Tom !

C’est alors que j’étais entré chez Teradyne et que j’avais fait la connaissance de Russ Ashdown, Ken Finder, Bob Copithorne, Chuck Studee et CK Srithran (devenu Kris Iyer). Mon chef était Ken et mes collègues étaient Chuck et CK. J’ai tant appris avec eux. Merci les gars !

J’ai ensuite rencontré Mike Carew, toujours chez Teradyne. Nous étions devenus le duo dynamique et avions écrit plusieurs systèmes. Lorsque vous aviez besoin que quelque chose soit fait vite et bien, il suffisait de demander au couple Bob et Mike. Nous avions pris beaucoup de plaisir à travailler ensemble. Merci encore, Mike !

Chez Teradyne, j’avais aussi connu Jerry Fitzpatrick. Au départ, c’était en jouant à Donjons & dragons. Nous avions rapidement décidé de collaborer et écrivions des logiciels sur un micro-ordinateur Commodore 64 pour assurer un soutien à l’équipe de recherche et développement. Nous avions ensuite lancé un nouveau projet de réceptionniste électronique, une sorte de standardiste automatisé. Nous avions passé plusieurs années sur ce projet, et Jerry était devenu le très bon ami qu’il est resté. Merci à toi, Jerry !

Chez Teradyne, on m’avait envoyé un an au Royaume-Uni. Avec Mike Kergozou, nous avions travaillé sur des sujets très variés, mais l’essentiel de mes souvenirs concerne les promenades à vélo et les pubs. C’est un programmeur très axé sur la qualité et la discipline, même s’il n’en conviendrait pas. Merci à toi, Mike !

À mon retour d’Angleterre en 1987, j’avais commencé à collaborer avec Jim Newkirk. Nous avions démissionné de Teradyne à quelques mois d’intervalle pour rejoindre une nouvelle entreprise, Clear Communications, dans laquelle nous avions passé plusieurs années à tenter de décrocher le gros lot, mais ce n’est jamais arrivé. Nous avions cependant continué notre chemin. Merci à toi, Jim !

Nous avions fini par créer ensemble la société Object Mentor. Jim est la personne la plus honnête, la plus disciplinée et la plus concentrée que j’ai eu la chance de rencontrer. Je ne peux même pas tenter d’énumérer tout ce que j’ai appris auprès de lui. Pour me faire pardonner, je lui ai dédié ce livre.

Bien d’autres gens ont croisé ma route et ont eu un impact sur ma vie professionnelle : Lowell Lindstrom, Dave Thomas, Michael Feathers, Bob Koss, Brett Schuchert, Dean Wampler, Pascal Roy, Jeff Langr, James Grenning, Brian Button, Alan Francis, Mike Hill, Eric Meade, Ron Jeffries, Kent Beck, Martin Fowler, Grady Booch et d’autres encore. Merci à tous !

Mais la personne avec laquelle j’ai le plus collaboré au long de ma vie est bien sûr ma chère épouse, Ann-Marie. Nous nous sommes mariés lorsque j’avais 20 ans ; elle venait d’en avoir 18, trois jours auparavant. Pendant quatre décennies, elle m’a accompagné, guidé et nourri d’amour. Je ne rêve que de vivre quatre autres décennies avec elle.

J’ai enfin comme collaborateurs et partenaires de mes projets mes propres enfants. Je travaille avec mon aînée, Angela, ma chaleureuse et intrépide assistante. Elle me maintient toujours sur le droit chemin et ne me laisse jamais oublier un rendez-vous. J’élabore des projets avec mon fils Micah qui a monté sa propre entreprise, 8thlight.com. Il est beaucoup plus doué que moi pour le côté commercial. Notre projet le plus récent, cleancoders.com, est passionnant !

Mon plus jeune fils, Justin, vient de rejoindre Mika chez 8thlight. Enfin, ma benjamine, Gina, est devenue ingénieure chimiste chez Honeywell.

Qui peut vous en apprendre plus que vos propres enfants ? Merci à vous, les chéris !

À propos de l’auteur

Robert C. Martin...