Pourquoi il n'est pas possible d'échanger les programmeurs : la programmation en tant que construction de la théorie

Par Peter Naur

Pourquoi les programmeurs ne sont pas interchangeables ? Voici l'essentiel d'un magnifique article de 1985 de Peter Naur qui fournit un argument convaincant sur les raisons pour lesquelles les programmeurs ne sont pas fongibles. On ne peut pas échanger les programmeurs comme les rouages d'une machine, parce que les programmeurs ne sont pas des producteurs de gadgets. Ils apportent une valeur ajoutée principalement grâce à leur compréhension des systèmes complexes, compréhension qu'il est difficile d'acquérir avec une documentation, aussi complète soit-elle.


Introduction

La présente discussion est une contribution à la compréhension de ce qu'est la programmation. Elle suggère que la programmation proprement dite devrait être considérée comme une activité par laquelle les programmeurs forment ou atteignent un certain type de compréhension, une théorie, des questions en jeu. Cette suggestion s'oppose à ce qui semble être une notion plus courante, à savoir que la programmation devrait être considérée comme la production d'un programme et de certains autres textes.

Les points de vue présentés ici trouvent en partie leur origine dans certaines observations de ce qui arrive réellement aux programmes et aux équipes de programmeurs qui s'en occupent, en particulier dans les situations résultant d'exécutions ou de réactions inattendues et peut-être erronées des programmes, ainsi qu'à l'occasion de modifications des programmes. La difficulté d'intégrer de telles observations dans une vision de la programmation axée sur la production suggère que cette vision est trompeuse. Le point de vue de la construction de la théorie est présenté comme une alternative.

Le contexte plus général de la présentation est la conviction qu'il est important d'avoir une bonne compréhension de ce qu'est la programmation. Si notre compréhension est inappropriée, nous ne comprendrons pas les difficultés qui surgissent dans l'activité et nos tentatives pour les surmonter donneront lieu à des conflits et à des frustrations.

Dans la présente discussion, nous commencerons par exposer certaines expériences de base essentielles. Elle sera suivie d'une explication de la théorie de la programmation, appelée "Theory Building View" (point de vue de la construction de la théorie). Les sections suivantes abordent certaines des conséquences du point de vue de la construction de la théorie.

La programmation et les connaissances des programmeurs

J'utiliserai le mot "programmation" pour désigner l'ensemble de l'activité de conception et de mise en œuvre de solutions programmées. Ce qui m'intéresse, c'est de faire correspondre une partie ou un aspect important d'une activité dans le monde réel à la manipulation formelle de symboles qui peut être effectuée par un programme fonctionnant sur un ordinateur. Avec une telle notion, il s'ensuit directement que l'activité de programmation dont je parle doit inclure le développement dans le temps correspondant aux changements qui se produisent dans l'activité du monde réel à laquelle correspond l'exécution du programme, en d'autres termes, les modifications du programme.

Une façon d'exprimer le point principal que je veux faire est que la programmation, dans ce sens, doit principalement être la construction par les programmeurs de connaissances d'un certain type, connaissances considérées comme étant fondamentalement la possession immédiate des programmeurs, toute documentation étant un produit auxiliaire, secondaire.

En toile de fond de l'élaboration plus poussée de ce point de vue dans les sections suivantes, le reste de la présente section décrira une expérience réelle de traitement de grands programmes qui m'a semblé de plus en plus significative au fur et à mesure que je réfléchissais aux problèmes. Dans les deux cas, l'expérience est la mienne ou m'a été communiquée par des personnes ayant un contact direct avec l'activité en question.

Le cas 1 concerne un compilateur. Il a été développé par un groupe A pour un langage L et a très bien fonctionné sur l'ordinateur X. Un autre groupe B a maintenant pour tâche d'écrire un compilateur pour un langage L + M, une modeste extension de L, pour l'ordinateur Y. Le groupe B décide que le compilateur pour L développé par le groupe A sera un bon point de départ pour sa conception, et passe un contrat avec le groupe A selon lequel il bénéficiera d'un soutien sous la forme d'une documentation complète, y compris des textes de programmes annotés et de nombreuses discussions écrites supplémentaires sur la conception, ainsi que de conseils personnels. L'arrangement a été efficace et le groupe B a réussi à développer le compilateur qu'il souhaitait. Dans le présent contexte, la question importante est celle de l'importance des conseils personnels du groupe A sur les questions relatives à la mise en œuvre des extensions M du langage. Pendant la phase de conception, le groupe B a fait des suggestions sur la manière dont les extensions devaient être prises en compte et les a soumises au groupe A pour examen. Dans plusieurs cas importants, il s'est avéré que les solutions suggérées par le groupe B ont été jugées par le groupe A comme n'utilisant pas les facilités qui étaient non seulement inhérentes à la structure du compilateur existant mais qui étaient longuement discutées dans sa documentation, et comme étant plutôt basées sur des ajouts à cette structure sous la forme de correctifs qui détruisaient effectivement sa puissance et sa simplicité. Les membres du groupe A ont été capables de repérer ces cas instantanément et de proposer des solutions simples et efficaces, entièrement encadrées par la structure existante. C'est un exemple qui montre que le texte complet du programme et la documentation supplémentaire ne suffisent pas à transmettre, même au groupe B très motivé, la vision plus profonde de la conception, cette théorie qui est immédiatement présente pour les membres du groupe A.

Dans les années qui ont suivi ces événements, le compilateur développé par le groupe B a été repris par d'autres programmeurs de la même organisation, sans l'aide du groupe A. Les informations obtenues par un membre du groupe A sur le compilateur à la suite de modifications ultérieures après une dizaine d'années ont montré clairement qu'à ce stade ultérieur, la puissante structure d'origine était toujours visible, mais rendue totalement inefficace par des ajouts amorphes de différentes natures. Ainsi, une fois de plus, le texte du programme et sa documentation se sont révélés insuffisants pour véhiculer certaines des idées de conception les plus importantes.

Le cas 2 concerne l'installation et le diagnostic de défaillance d'un grand système en temps réel destiné à surveiller les activités de production industrielle. Le système est commercialisé par son producteur, chaque livraison du système étant adaptée individuellement à son environnement spécifique de capteurs et de dispositifs d'affichage. La taille du programme livré dans chaque installation est de l'ordre de 200 000 lignes. L'expérience pertinente tirée de la manière dont ce type de système est géré concerne le rôle et le mode de travail du groupe de programmeurs chargés de l'installation et de la recherche de pannes. Tout d'abord, ces programmeurs se sont intéressés de près au système à plein temps pendant plusieurs années, depuis la conception du système. Deuxièmement, lorsqu'ils diagnostiquent une erreur, ces programmeurs s'appuient presque exclusivement sur leur connaissance du système et sur le texte annoté du programme, et sont incapables de concevoir une quelconque documentation supplémentaire qui leur serait utile. Troisièmement, d'autres groupes de programmeurs qui sont responsables de l'exploitation d'installations particulières du système et qui reçoivent donc une documentation sur le système et des conseils complets sur son utilisation de la part du personnel du producteur, rencontrent régulièrement des difficultés qui, après consultation du programmeur d'installation et de recherche de pannes du producteur, sont dues à une mauvaise compréhension de la documentation existante, mais qui peuvent être facilement résolues par les programmeurs d'installation et de recherche de pannes.

La conclusion semble inéluctable qu'au moins pour certains types de grands programmes, l'adaptation, la modification et la correction continues des erreurs qu'ils contiennent dépendent essentiellement d'un certain type de connaissances possédées par un groupe de programmeurs qui sont étroitement et continuellement en contact avec eux.

La notion de théorie selon Ryle

Si l'on admet que la programmation doit impliquer, en tant qu'élément essentiel, une accumulation de connaissances de la part des programmeurs, la question suivante est de caractériser plus précisément ces connaissances. Nous examinerons ici la suggestion selon laquelle les connaissances des programmeurs devraient être considérées comme une théorie, au sens de Ryle [1949]. Très brièvement, une personne qui a ou possède une théorie dans ce sens sait comment faire certaines choses et peut en outre soutenir l'action réelle par des explications, des justifications et des réponses à des questions concernant l'activité en question. On peut noter que la notion de théorie de Ryle apparaît comme un exemple de ce que K. Popper [Popper et Eccles, 1977] appelle des objets non incarnés du monde 3 et qu'elle a donc un statut philosophique défendable. Dans la présente section, nous décrirons plus en détail la notion de théorie de Ryle.

Ryle [1949] développe sa notion de théorie dans le cadre de son analyse de la nature de l'activité intellectuelle, en particulier de la manière dont l'activité intellectuelle diffère de l'activité simplement intelligente et la dépasse. Dans un comportement intelligent, la personne fait preuve, non pas d'une connaissance particulière des faits, mais de la capacité de faire certaines choses, telles que faire et apprécier des blagues, parler grammaticalement ou pêcher. Plus particulièrement, la performance intelligente se caractérise en partie par le fait que la personne fait bien les choses, selon certains critères, mais aussi par sa capacité à appliquer les critères de manière à détecter et à corriger les lacunes, à apprendre des exemples des autres, etc. Il convient de noter que cette notion d'intelligence ne repose pas sur l'idée que le comportement intelligent dépend du fait que la personne suit ou adhère à des règles, des prescriptions ou des méthodes. Au contraire, l'acte même d'adhérer à des règles peut être fait plus ou moins intelligemment ; si l'exercice de l'intelligence dépendait de l'adhésion à des règles, il faudrait des règles sur la façon de suivre les règles, et sur la façon de suivre les règles sur l'adhésion aux règles, etc. dans une régression infinie, ce qui est absurde.

Ce qui caractérise l'activité intellectuelle, au-delà de l'activité simplement intelligente, c'est la construction et la possession d'une théorie, la théorie étant entendue comme la connaissance qu'une personne doit posséder non seulement pour faire certaines choses intelligemment, mais aussi pour les expliquer, répondre à des questions à leur sujet, argumenter à leur sujet, etc. Une personne qui a une théorie est prête à s'engager dans de telles activités ; en construisant la théorie, la personne essaie de l'obtenir.

La notion de théorie au sens où nous l'entendons ici s'applique non seulement aux constructions élaborées de domaines de recherche spécialisés, mais également aux activités auxquelles toute personne ayant reçu une éducation participera à certaines occasions. Même des activités peu ambitieuses de la vie quotidienne peuvent donner lieu à une théorisation, par exemple lorsqu'il s'agit de planifier l'emplacement d'un meuble ou la manière de se rendre à un endroit donné en utilisant certains moyens de transport.

La notion de théorie employée ici n'est explicitement pas limitée à ce que l'on peut appeler la partie la plus générale ou la plus abstraite de l'intuition. Par exemple, pour comprendre la théorie de la mécanique de Newton telle qu'elle est comprise ici, il ne suffit pas de comprendre les lois centrales, telles que la force égale la masse multipliée par l'accélération. En outre, comme le décrit plus en détail Kuhn [1970, p. 187 et suivantes], la personne qui possède la théorie doit comprendre la manière dont les lois centrales s'appliquent à certains aspects de la réalité, afin de pouvoir reconnaître et appliquer la théorie à d'autres aspects similaires. Une personne possédant la théorie de la mécanique de Newton doit ainsi comprendre comment elle s'applique aux mouvements des pendules et des planètes, et doit être capable de reconnaître des phénomènes similaires dans le monde, afin d'être en mesure d'utiliser correctement les règles mathématiquement exprimées de la théorie.

La dépendance d'une théorie à l'égard de certains types de similitudes entre des situations et des événements du monde réel explique pourquoi la connaissance détenue par un détenteur de la théorie ne pourrait pas, en principe, être exprimée en termes de règles. En effet, les similitudes en question ne sont pas et ne peuvent pas être exprimées en termes de critères, pas plus que ne peuvent l'être les similitudes de nombreux autres types d'objets, tels que les visages humains, les mélodies ou les goûts du vin.

La théorie à construire par le programmeur

Selon la notion de théorie de Ryle, ce qui doit être construit par le programmeur est une théorie sur la façon dont certaines affaires du monde seront traitées ou soutenues par un programme informatique. Dans le cadre de la programmation du point de vue de la construction de la théorie, la théorie élaborée par les programmeurs prime sur d'autres produits tels que les textes des programmes, la documentation destinée à l'utilisateur et la documentation supplémentaire telle que les spécifications.

En défendant le point de vue de la construction de la théorie, la question fondamentale est de montrer comment les connaissances possédées par le programmeur en vertu de sa théorie transcendent nécessairement, et de manière essentielle, celles qui sont consignées dans les produits documentés. La réponse à cette question est que les connaissances du programmeur transcendent celles figurant dans la documentation dans au moins trois domaines essentiels :

1. Le programmeur qui possède la théorie du programme peut expliquer comment la solution se rapporte aux affaires du monde qu'elle aide à traiter. Cette explication devra porter sur la manière dont les affaires du monde, tant dans leurs caractéristiques générales que dans leurs détails, sont, d'une certaine manière, transposées dans le texte du programme et dans toute documentation supplémentaire. Le programmeur doit donc être en mesure d'expliquer, pour chaque partie du texte du programme et pour chacune de ses caractéristiques structurelles globales, à quel aspect ou activité du monde il correspond. Inversement, pour tout aspect ou activité du monde, le programmeur est en mesure d'indiquer la manière dont il s'inscrit dans le texte du programme. La plus grande partie des aspects et activités du monde se situera bien sûr en dehors du champ d'application du texte du programme, car elle n'est pas pertinente dans le contexte. Cependant, la décision de considérer une partie du monde comme pertinente ne peut être prise que par quelqu'un qui comprend le monde dans son ensemble. Cette compréhension doit être apportée par le programmeur.
2. Le programmeur qui possède la théorie du programme peut expliquer pourquoi chaque partie du programme est ce qu'elle est, en d'autres termes, il est capable d'étayer le texte du programme par une sorte de justification. La base finale de la justification est et doit toujours rester la connaissance ou l'estimation directe et intuitive du programmeur. Il en va de même lorsque la justification fait appel au raisonnement, éventuellement à l'application de règles de conception, à des estimations quantitatives, à des comparaisons avec d'autres solutions, etc., l'important étant que le choix des principes et des règles, et la décision qu'ils sont pertinents pour la situation en question, doivent en dernière analyse rester une question de connaissance directe du programmeur.
3. Le programmeur qui possède la théorie du programme est en mesure de répondre de manière constructive à toute demande de modification du programme afin de soutenir les affaires du monde d'une nouvelle manière. La conception de la meilleure façon d'intégrer une modification dans un programme établi dépend de la perception de la similitude de la nouvelle demande avec les facilités opérationnelles déjà intégrées dans le programme. Le type de similitude qui doit être perçu est une similitude entre des aspects du monde. Il n'a de sens que pour l'agent qui connaît le monde, c'est-à-dire pour le programmeur, et ne peut être réduit à un ensemble limité de critères ou de règles, pour des raisons similaires à celles évoquées plus haut pour lesquelles la justification du programme ne peut être ainsi réduite.

Si la discussion de la présente section présente quelques arguments de base en faveur de l'adoption du point de vue de la construction de la théorie, l'évaluation de cette conception doit tenir compte de la mesure dans laquelle elle peut contribuer à une compréhension cohérente de la programmation et de ses problèmes. Ces questions seront abordées dans les sections suivantes.

Problèmes et coûts des modifications de programmes

L'une des principales raisons pour lesquelles nous avons proposé le point de vue de la construction de la théorie dans la programmation est le désir d'établir une vision de la programmation qui permette de bien comprendre les modifications apportées aux programmes. Cette question sera donc la première à être analysée.

Tout le monde semble s'accorder sur un point : les logiciels seront modifiés. Il arrive invariablement qu'un programme, une fois mis en oeuvre, ne soit perçu que comme une partie de la réponse aux problèmes posés. En outre, l'utilisation même du programme inspirera des idées pour d'autres services utiles que le programme devrait fournir. D'où la nécessité de trouver des moyens de gérer les modifications.

La question des modifications de programme est étroitement liée à celle des coûts de programmation. Face à la nécessité de modifier le mode de fonctionnement du programme, on espère réaliser des économies en apportant des modifications à un texte existant plutôt qu'en écrivant un programme entièrement nouveau.

L'idée qu'il devrait être possible de modifier un programme à faible coût mérite d'être analysée de plus près. Il convient tout d'abord de noter qu'une telle attente ne peut être étayée par une analogie avec les modifications d'autres constructions complexes réalisées par l'homme. Lorsque des modifications sont parfois apportées, par exemple dans le cas de bâtiments, il est bien connu qu'elles sont coûteuses et, en fait, la démolition complète du bâtiment existant suivie d'une...