Rapport de voyage ICSE 2018: 50 ans d'ingénierie logicielle

La plupart des présidents généraux et des présidents de programme des 40 réunions de la CISP.

Le domaine de la recherche en génie logiciel a 50 ans cette année; la plus grande, la plus ancienne et la meilleure des conférences sur le génie logiciel, la Conférence internationale sur le génie logiciel, a 40 ans. La conférence de cette année a été une excellente occasion pour la communauté de revenir sur le demi-siècle de recherches et de demander: «Qu'avons-nous appris? Qu'avons-nous oublié? Qu'est-ce qui nous manque? »J'ai passé la semaine à Göteborg, en Suède, à débattre de cette question, en réfléchissant aux nombreuses allocutions et discours perspicaces qui ont répondu à ces questions, mais aussi en partageant mes propres idées sur la manière d'aller de l'avant à travers deux conférences invitées.

Pour lancer ma première journée complète, j'ai prononcé le discours d'ouverture aux dépôts de logiciels Mining.

J'ai commencé à travailler à l'ICSE en donnant une allocution conjointe au CIPC 2018 et au MSR 2018 sur le besoin urgent de travail interdisciplinaire et de théorie dans la recherche en génie logiciel, en utilisant les communautés qui se concentrent sur la compréhension et l'exploration minière comme exemples de ces points plus vastes. J'ai écrit sur mon discours dans un précédent post, résumant mes arguments. Après mon exposé et tout au long de la conférence, j’ai eu des conversations très intéressantes avec deux chercheurs expérimentés qui avaient du mal à comprendre ce que je voulais dire par théorie, mais aussi un nouveau doctorat. les étudiants fascinés par le potentiel de la théorie à rendre leur travail plus percutant. J’ai eu une conversation de groupe avec plusieurs étudiants au doctorat de la CMU sur la nature de la théorie, son apparence, la transformation des études que nous menons et la manière dont nos résultats peuvent être plus profonds. J'ai également parlé à un ingénieur d'Adobe Analytics qui avait du mal à convaincre les adoptants internes d'outils d'analyse. C'était une opportunité fascinante d'essayer d'influer sur l'intégration de la théorie dans les travaux de la prochaine génération de chercheurs et d'ingénieurs, mais je me suis demandé comment enseigner efficacement l'utilisation de la théorie.

Lundi, j'ai passé une partie de mon temps dans les sessions MSR et ICPC, entendant parler des dernières explorations en matière de perception des messages d'erreur, de compréhension des modèles de conception et d'autres efforts pour étudier la compréhensibilité. Un document reproduisait une évaluation de 121 mesures de complexité liées au code afin de déterminer si elles correspondaient à l’expérience de la compréhensibilité autodéclarée par les développeurs, en concluant que la longueur et les noms de variables étaient conjointement prédictifs des évaluations des développeurs. Il existe une utilisation vraiment intelligente des données dans ces petites conférences regroupées en un même lieu, qui posent des questions vraiment convaincantes au carrefour de la compréhension et de l’exploitation minière. Comme je l’ai noté dans mon discours, ils ont vraiment besoin de théorie sur la compréhension, mais les modèles qu’ils découvrent sont une bonne base pour développer ces théories.

Dans l'après-midi de lundi, j'ai eu une conversation captivante avec Tim Menzies sur les avantages relatifs des modèles profonds par rapport aux modèles peu profonds. Il a répondu à mon discours en partie avec surprise que je n'avais pas formulé de critiques plus approfondies de la communauté minière des référentiels, mais également que je n'avais pas reconnu le pouvoir stupéfiant des modèles simples et superficiels d'optimiser et d'adapter toutes sortes de décisions logicielles. ingénierie. Son argument était essentiellement que dans certains cas, voire peut-être, nous n'avons pas besoin d'expliquer pourquoi les outils, les systèmes ou les processus fonctionnent, ils doivent simplement fonctionner. Nous avons résolu les désaccords et conclu que nous avions probablement besoin de modèles de toutes sortes de profondeurs (des théories aux lois inexpliquées, en passant par les moteurs de prédiction inconsidérés mais précis). Une telle diversité est probablement le signe d'un discours académique sain.

Le banquet MSR au Musée de la culture mondiale de Göteborg.

Le lundi soir était un banquet pour la conférence sur les dépôts de logiciels miniers. J'ai eu une riche série de conversations avec Mei Nagappan, Andy Zaidman et Michael Godfrey. Nous avons parlé de tout, qu'il s'agisse de la permanence et de la promotion, de l'apprentissage à grande échelle du CS, de notre historique personnel d'apprentissage au programme et de notre rôle de gardien de l'enseignement dans le CS. Pour moi, de telles conversations sont la substance profonde des réseaux universitaires: ce sont des conversations sur nos vies, nos idées et leurs interactions.

Abram parle de la nécessité d'un progrès scientifique progressif.

Mardi matin, Abram Hindle a prononcé un discours sur le papier le plus influent: «Que nous disent les grands commits? Une étude taxonomique sur les gros commits? »Ce qui était important dans cet article, c’est qu’il était l’un des premiers à ne pas seulement faire progresser les techniques d’extraction, mais aussi à poser une question sur le contenu des référentiels, ce qui a amené le sujet à des questions plus scientifiques sur les logiciels. ingénierie, pas seulement des techniques pour l'exploitation minière. Ce que j’ai trouvé très intéressant dans ce travail, c’est la façon dont il était scientifiquement exprimé: il a affirmé avec force que les valeurs aberrantes sont importantes et qu’elles ne sont pas ignorables, et que les valeurs aberrantes engagées sont des indicateurs vraiment critiques de la nature de l’évolution du logiciel. Il se concentrait également sur une analyse de contenu détaillée des commits, qui était (et est toujours) une méthode rare dans toute recherche en fouille de données. Abram a également avancé un argument convaincant: rejeter les articles pour ne pas avoir de résultats immédiats gêne notre science et donc notre avenir, et va à l’encontre de l’érudition. Au cours de la période de questions, Abram a fait quelques remarques éclairantes sur l’économie de la recherche et sur la manière dont elle peut détourner les questions que nous poursuivons et la profondeur de la recherche scientifique que nous permettons.

Pendant une pause, Lutz Prechelt m'a posé une question fascinante: pourquoi, malgré la complexité et la complexité des logiciels et les développeurs, le logiciel est-il néanmoins construit, adopté et utilisé de manière productive? J'ai réfléchi un moment et partagé ma grande théorie. Mon explication était que le logiciel, bien qu’il ait un espace d’exécution réellement infini et qu’il soit infiniment incompréhensible pour les développeurs, n’a en réalité qu’un petit espace d’états pertinent utilisé dans la pratique par les utilisateurs. Cela signifie que malgré toute cette complexité, les développeurs sont capables d’acquérir juste assez de connaissances sur cet espace d’exécutions pertinent et de s’assurer que les logiciels sont efficaces et robustes à leur place. Ensuite, même lorsque les logiciels ne sont ni efficaces, ni robustes, les utilisateurs sont résilients face à la plupart des échecs rencontrés, trouvent des solutions de contournement ou modifient leurs objectifs en fonction du comportement. Cette théorie de la résilience explique pourquoi un logiciel est précieux malgré sa fragilité. Cela ne veut pas dire que les échecs logiciels importent peu: il y a de graves échecs, souvent dus à des développeurs qui n’ont pas une idée précise des parties de l’espace-système d’un logiciel complexe qui comptent vraiment sur le terrain. De plus, les développeurs ne disposent souvent pas des outils ni des données nécessaires pour obtenir cette connaissance précise. En outre, il existe de nombreux sous-composants de systèmes purement automatisés que nous devons pouvoir vérifier formellement pour éviter les pannes graves en aval. Il existe également d’importantes considérations relatives à l’être humain qui nécessitent une attention particulière pour obtenir les résultats escomptés, qui nécessitent des méthodes d’assurance-maladie à la clé. Donc, aussi résistant que le monde puisse supporter des logiciels fragiles, nous pouvons et devons faire mieux.

J'ai pris une pause mardi midi pour discuter passionnément avec un collègue junior de conseils aux étudiants en doctorat. Il a posé d’excellentes questions qui m’ont permis de réfléchir à mes pratiques. J'ai beaucoup parlé de la définition de la culture et de ma nouvelle stratégie d'écriture d'un document d'intégration qui définit les attentes. J'ai parlé de la sécurité psychologique en tant que fondement de l'établissement de relations de confiance avec mes étudiants et avec mon équipe. J’ai évoqué le besoin critique d’appliquer et de modéliser les normes de mon document d’intégration afin de renforcer la culture de mon laboratoire. J'ai partagé des idées sur la manière de rassembler les élèves pour renforcer la responsabilité, la diversité des idées et la fréquence des réactions. J'ai également abordé les tensions préexistantes pouvant découler du besoin de publications, mais aussi de la nécessité de donner aux étudiants un espace pour apprendre, et de la manière de résoudre ces tensions en maintenant un fil séparé des recherches effectuées par le premier auteur. Plus important encore, j’ai rappelé à cette collègue que cet apprentissage ne s’arrêtait pas. Je connais des collègues de haut niveau qui cherchent toujours des conseils après des décennies d’apprentissage.

J'ai eu un merveilleux dîner mardi soir avec Thomas LaToza et Ph.D. August Shi, étudiant dans lequel nous avons longuement discuté de la recherche fondamentale et appliquée en génie logiciel, du rôle des sciences sociales dans la recherche en génie logiciel et du besoin de comptes rendus plus honnêtes et fondés sur la théorie des hypothèses sous-jacentes du travail technique effectué sur le terrain.

Magnus Frodigh, président d’Ericsson Research, a prononcé mercredi le discours liminaire sur les communications sans fil et la 5G. Il a commencé par prédire un rythme de changement rapide dans nos expériences numériques, mais également un rythme de changement plus lent dans l'infrastructure de réseau. Il a fait valoir que la stabilité de la norme 5G impliquerait toutes sortes de nouvelles infrastructures de transformation dans l'Internet des objets, y compris la communication machine à machine en temps réel. Il s'est plongé dans les détails de l'infrastructure 5G, que je trouvais aride et peu pertinent pour l'ingénierie logicielle, mais la vision irrésistible enfouie dans le discours était l'ampleur inimaginable de la connectivité entre les personnes et les machines, qui permet essentiellement d'éliminer la latence. Magnus a fait valoir que cela faciliterait considérablement le prototypage de nouvelles expériences, car les systèmes peuvent être entièrement composés de services en réseau à faible temps de latence plutôt que de déploiements de matériel.

Pendant la pause du mercredi matin, Walter Tichy, James Herbsleb et moi-même avons eu une conversation fructueuse sur la manière de transformer l’utilisation et le développement de la théorie par la communauté de recherche en génie logiciel. Nous avons commencé par observer que le domaine comporte des théories, elles sont simplement implicites et, si elles sont explicitées, elles pourraient nous amener à repenser nos hypothèses et nos orientations de recherche. Par exemple, le domaine contient des théories sur le pouvoir de l'abstraction, des notions de prédiction des erreurs dans la conception du langage de programmation et le fonctionnement de la compréhension du programme. Nous ne faisons tout simplement pas expliciter ces théories. James avait également donné un discours théorique sur la théorie, et nous avions tous deux reçu des réponses chaleureuses à nos appels en faveur d'une théorie plus approfondie. Nous pensons donc que le domaine est prêt à apprendre. Nous avons réfléchi aux moyens d’éduquer la communauté, notamment au développement de matériaux légers pour enseigner aux nouveaux étudiants au doctorat ou aux professeurs intéressés. Nous avons discuté de la possibilité d’organiser un Dagstuhl pour développer et déployer ce matériel.

Chris Parnin discute de la complexité de la complexité de l'enseignement.

J’ai passé le reste de la journée de mercredi à assister aux sessions consacrées à l’enseignement et à la formation en génie logiciel (que je coprésiderai en 2020, mais j’estime aussi que c’est très important et au centre de mes intérêts en informatique). Ce titre publie une recherche en informatique rigoureuse et révisée sur le génie logiciel. Chris Parnin a lancé la première séance avec une conférence sur l'utilisation d'iTrust, une implémentation logicielle complexe et volumineuse, pour enseigner le génie logiciel. Il a constaté que les étudiants avaient beaucoup plus tard apprécié le profond engagement d'un grand système complexe, mais ils ne l'avaient pas apprécié tout au long du cours. Travailler avec le code hérité était écrasant. Ils ont révisé le cours en alignant les activités de classe sur le projet lui-même, ce qui a suscité des sentiments beaucoup plus positifs à propos du cours (comme il fallait s'y attendre; les élèves ont besoin d'un récit cohérent autour des activités de classe pour maintenir leur engagement). Une autre conversation a révélé que la visionnage actif de vidéos, au cours duquel les apprenants commentent le contenu et commentent les commentaires, a renforcé l'engagement dans la visualisation de vidéos. Certaines discussions ont porté sur les laboratoires, les pierres angulaires et d’autres projets d’apprentissage par l’expérience. Généralement, ces études ont montré que l'apprentissage par l'expérience est vraiment difficile à mettre en œuvre sur le plan logistique, difficile à rendre authentique et très difficile à évaluer. On dirait que nous avons besoin de théories d’apprentissage expérientiel pour organiser ce travail.

Reid Holmes discutant des choses que les élèves ont aimé apprendre.

Reid Holmes a présenté une belle étude longitudinale du programme d’apprentissage par l'expérience du Canada destiné aux étudiants en informatique hautement performants (projets de premier cycle Capstone Open Source). L'étude a permis de découvrir des expériences incroyablement positives, les étudiants valorisant fortement l'application de leurs connaissances en classe à des tâches réelles et novatrices, pour de vrais projets avec une communauté d'utilisateurs, tout en bénéficiant du mentorat de développeurs réels. La manière dont les étudiants sont sélectionnés est sélectionnée: le programme choisit explicitement les meilleurs étudiants de plusieurs établissements, ce qui évite de nombreux problèmes d’apprentissage qui pourraient survenir avec des étudiants moins préparés.

La forêt tropicale de l’Universeum était très humide!

La réception du mercredi soir a eu lieu à l’Universeum, un musée de sciences naturelles regorgeant d’animaux, de poissons et d’une immense forêt tropicale humide. C'était un contexte vraiment intéressant pour une réception, car plutôt que d'être un grand espace ouvert pour la conversation, il était rempli d'expositions interactives qui engageaient les participants autour du jeu et de l'exploration. Les expositions n’étaient ni particulièrement attrayantes ni convaincantes, mais elles étaient suffisamment bonnes pour déclencher toutes sortes de conversations intéressantes que nous n’aurions probablement pas eues autrement. J'ai parlé aux participants des monstres de Gila, des crotales, des méduses, de la maintenance logicielle des expositions logicielles et d'un large éventail de cynisme qui s'est infiltré dans l'informatique universitaire.

Jeudi matin, j'ai déjeuné avec Brendan Murphy, Laurie Williams et UW Ph.D. étudiant Calvin Loncaric dans la salle de petit-déjeuner de notre hôtel. Nous avons eu une vaste discussion sur deux grands défis qui me tenaient à cœur: réconcilier les systèmes formels tels que les langages de programmation avec les systèmes humains et sociaux, et réconcilier les systèmes statistiques tels que l’apprentissage automatique avec les systèmes humains et sociaux. À mon avis, ce sont les deux plus grands défis majeurs en informatique, et pourtant la plupart des informaticiens les ignorent. Brendan avait beaucoup à dire sur les complexités de l'unification de l'analyse de données et de l'apprentissage automatique avec de vrais projets, Laurie a beaucoup parlé des mêmes défis en matière de comptabilité pour la sécurité dans le développement de logiciels, et Calvin a examiné ces problèmes dans son propre travail de synthèse de structure de données, où des considérations sur la compréhensibilité du code synthétisé et la facilité d'apprentissage de son langage de spécification sont des questions ouvertes.

Fred Brooks Jr., interprète de l'histoire.

Il y avait deux discours d'ouverture jeudi matin. Fred Brooks, Jr., auteur de l'ouvrage The Mythical Man-Month sur la gestion de projets logiciels, présente une rétrospective. Fred a parlé de l'évolution des programmes, logiciels, systèmes logiciels, produits logiciels. Il a ensuite défini le génie logiciel comme la discipline de la fabrication de produits logiciels. Il a évoqué les grandes idées de l’histoire du génie logiciel, notamment les programmes de von Neumann en tant que données et langages de programmation de haut niveau tels que COBOL et FORTRAN. Dans les années 60, la crise du logiciel (le défi de la construction de grands systèmes) a conduit à une idée de l’ingénierie logicielle en tant qu’ingénierie. La grande reconnaissance était que la croissance de la complexité du projet n’était pas linéaire. Une grande partie de cela a conduit à des contributions systèmes, comme le débogage interactif de Tom Kilburn et le système d’exploitation à partage de temps de Fernando Corbato, les systèmes de base de données, les idées de vérification formelle de Robert Floyd et Tony Hoare et l’orientation par objet de Simula. Dans les années 70, David Parnas dissimulait des informations, les types de données abstraits de Barbara Liskov, le raffinement supplémentaire de Harlan Mills et de Niklaus Wirth, les inspections de code de Michael Fagan et la gestion de projets logiciels. Barry Boehm a également posé des questions sur les exigences et la validation des exigences. Il a vivement recommandé le webinaire ACM de Grady Booch sur l’histoire du génie logiciel et les contributions de toute sa vie à Barry Boehm.

Margaret Hamilton partage des histoires de mainframes de programmation.

La deuxième intervenante jeudi matin était Margaret Hamilton, qui envisageait l'expression «génie logiciel». Elle était étudiante en mathématiques lorsqu'elle a décidé de faire un stage au MIT pour développer un logiciel de météo sur le LGP30, et a développé un intérêt pour le logiciel. Elle a finalement construit l'Apollo logiciels qui ont permis aux États-Unis d’atterrir sur la lune. Son exposé, «La langue en tant qu’ingénieur logiciel», a abordé les grands problèmes: intégration, évolutivité difficile, réutilisation difficile et logiciel défaillant. Elle a demandé pourquoi nous avions fait si peu de progrès en 50 ans. Elle a soutenu qu'il y en avait. Il n'y avait pas de champ avant; maintenant il y a. Nous avons défini les termes. Mais la réalité est que le génie logiciel est un travail distinctement humain, distinctement social et distinctement intellectuel, et nous n’avons toujours pas à nous attaquer à la plupart de ces facteurs. Elle a donné des exemples des défis fondamentaux de HCI liés à la création de systèmes interactifs entre les personnes, les logiciels, les erreurs et la récupération des erreurs, et expliqué comment ceux-ci étaient essentiels pour atterrir sur la Lune. Elle a compris que les systèmes sont asynchrones, distribués et par événement, et que les langages utilisés pour écrire des logiciels devraient en tenir compte. Elle a équilibré cela avec une discussion sur le besoin de planification via une architecture basée sur des modèles réutilisables et fiables. J'étais fier de voir dans le Q & R la reconnaissance par la communauté de son histoire, de sa valeur et des origines lointaines de certaines des plus grandes idées du secteur.

Miryung Kim de UCLA parle d'une étude fascinante sur les rôles de la science des données.

Jeudi, j'ai présidé une session intitulée «Étudier les ingénieurs logiciels», qui comportait quatre études empiriques fascinantes, notamment deux publications du TSE, dont la première est une revue. La première, intitulée «Comprendre les besoins des développeurs en matière de dépréciation en tant que fonction de langage» (écrite par Anand Sawant de la TU Delft) a mis en évidence de nombreuses tendances utiles concernant l'utilisation et la mauvaise utilisation des fonctionnalités de dépréciation, en identifiant les besoins en termes de dates de dépréciation, d'avertissements relatifs à la gravité et plus encore. des types d'avertissement. Le deuxième article, intitulé «Sur la dichotomie du comportement de débogage entre programmeurs» (rédigé par Moritz Beller de la TU Delft), a révélé que, dans la pratique, les outils de débogage sont rarement utilisés, que le «débogage printf» reste dominant et que la connaissance des outils de débogage est assez importante. faible. Le premier article de journal de la session, intitulé «Mesure de la compréhension d'un programme: une étude de terrain à grande échelle avec des professionnels» (Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing et Shanping Li), a révélé que les développeurs passaient la majorité de leur temps à comprendre code, qu’ils utilisent des navigateurs Web et des éditeurs pour comprendre le code, et que plus un développeur a de l’expérience, moins il passe de temps en compréhension. Le dernier article de la session, «Scientifiques des données dans les équipes logicielles: état de l’art et défis» (Miryung Kim, Thomas Zimmermann, Robert DeLine et Andrew Begel), a mené une enquête auprès de 793 scientifiques spécialisés dans les données. ensemble de 9 types de rôles en science des données: polymathes, évangélistes de données, préparateurs de données, façonneurs de données, constructeurs de plates-formes, personnes au clair de lune de niveaux différents, et acteurs perspicaces, qui ont interprété les données et les ont utilisées pour prendre des décisions. Cette riche déconstruction ou différents rôles semblent vraiment puissants pour informer l’enseignement de la science des données.

La dernière session de jeudi était une célébration des 50 ans du génie logiciel. Brian Randell a présenté une rétrospective du premier génie logiciel en 1968. Brian a expliqué à quel point l’informatique n’avait encore que très peu été inventée; pas d'internet, pas de réseaux, pas de réutilisation. Et pourtant, tous les problèmes étaient présents: tests, exactitude, gestion, etc. Brian a distingué entre programmation et ingénierie logicielle en définissant l'ingénierie logicielle comme «Le développement multi-personnes de programmes multi-personnes». (Il ne se souvient pas avoir dit cela.) , mais David Parnas insiste sur le fait qu’il l’a fait). Il a conclu que le domaine avait grandi au-delà de sa maturité, se demandant si nous avions réussi à le qualifier de discipline d'ingénierie et réprimandant la communauté pour avoir inventé un autre langage et une autre technique.

La conférence de Brian a été suivie par un panel de quatre des premiers participants à la conférence de 1968. Une des questions dont ils ont discuté était ce qu’ils regrettaient des cinquante dernières années. Ils ont évoqué le manque d'intérêt pour l'ingénierie des exigences, le manque d'attention pour la désinformation, le manque d'attention pour la maintenance des logiciels. Ils étaient déçus dans les années 60 et ils sont déçus maintenant. Certains des panélistes étaient enthousiasmés par les méthodes formelles mais déçus de leur absence d'adoption. Ils ont également été déçus par le peu de connaissances que nous avons découvertes sur la manière de guider les décisions de conception en ce qui concerne les qualités logicielles. Dans l’ensemble, cependant, il semblait y avoir peu de consensus sur le point de savoir si les choses s’étaient améliorées ou non. Nous construisons certes des choses plus complexes, mais sont-elles meilleures, plus ponctuelles?

Poisson, bande de couverture et diaporamas

Le banquet du jeudi soir était dans un chantier naval et était un étrange pastiche d'activités. Il y avait un repas de style banquet, une scène en plein air avec Ph.D. étudiants chantant de la musique rock et un groupe de reprises suédois chantant des chansons pop des années 1990 et 2000 pendant le dîner, tandis qu'une hôtesse a rendu hommage à la communauté du génie logiciel et a invité divers organisateurs de la conférence sur la scène à les remercier. Au cours du dîner, un diaporama a été diffusé avec toutes sortes de logos de produits logiciels arbitraires de l’histoire de l’informatique, avec occasionnellement une vidéo rétrospective avec des interviews de personnalités du génie logiciel. C'était farfelu, disjoint et désorientant, surtout quand un groupe de participants a découpé un coin de l'espace de l'événement pour danser.

Soirée dansante en génie logiciel!Robert McClure, l'un des participants à la conférence de l'OTAN de 1968.

Vendredi matin, j’ai trouvé un des panélistes de la rétrospective de jeudi, Robert McClure, assis seul pendant la pause et j’ai donc décidé de commencer une conversation. Il était l'un des premiers participants à la conférence de 1968 et un leader d'opinion actif dans l'industrie prônant le progrès. Je lui ai demandé ce qui avait changé en 50 ans, ce qui n’avait pas changé et quelle était sa conception du progrès. Nous avons eu une conversation fascinante et diversifiée sur de nombreuses questions fondamentales en génie logiciel. Il a commencé par aborder certaines des différences critiques entre la conception de ce que fait un logiciel (ce qui nécessite de comprendre un problème et son contexte), la conception technique (qui nécessite de spécifier soigneusement une solution) et l’ingénierie (qui est une pure implémentation de cette spécification). Robert a comparé le génie logiciel aux autres disciplines du génie. Je lui ai donc demandé quelles étaient, à son avis, les différences fondamentales, le cas échéant. Il a suggéré que c'était une question de degré. J'ai supposé que la différence essentielle était le degré de confiance d'un concepteur ou d'un concepteur technique dans la compréhension d'un problème ou d'une spécification; comprendre le site sur lequel vous construisez un pont repose sur les sciences naturelles, qui sont prévisibles à un degré qui n’est pas le cas des systèmes humains, sociaux et organisationnels pour lesquels le logiciel est généralement conçu. Ce manque de confiance crée un besoin de prototypage, de retour d'information et d'évolution qui n'est pas aussi nécessaire pour les autres disciplines de l'ingénierie (et aussi moins faisable). Nous avons également parlé de l'éducation nécessaire pour toutes ces compétences et du taux de changement auquel il s'attendait. Au cours des 50 dernières années, il s’attendait à beaucoup plus de changements qu’il n’avait observés et il a supposé que la nature humaine était beaucoup plus résistante au changement qu’il ne l’avait jamais cru. J'ai suggéré qu'il pourrait s'agir simplement d'un échec de l'efficacité de l'éducation, combiné à l'augmentation rapide du nombre de développeurs, de 10 000 environ en 1968 à 30 millions en 2018. Il m'a encouragé à modérer mes attentes en matière de changement; Je lui ai dit qu'en tant que professeur titulaire, j'y étais pour les 40 prochaines années et je serais patiente.

Brian Randell, historien en génie logiciel.

Par hasard, j’ai aussi trouvé Brian Randell, le conférencier principal en ingénierie logicielle de 50 ans, assis seul. Je lui ai demandé pourquoi il pensait que la deuxième conférence de l'OTAN était si décevante et quel effet il pensait que cela aurait sur les décennies à venir de recherche et de pratique en génie logiciel. Il a expliqué qu'une grande partie du problème résidait dans le fait que la deuxième année, il y avait des divisions entre les deux. Premièrement, certaines personnes ont imaginé un monde dans lequel nous pourrions expédier des logiciels libres complètement défectueux, tandis que d’autres ont estimé qu’une telle chose n’était pas possible et que nous devrions planifier en conséquence. Dans une deuxième dimension, certaines personnes souhaitaient déconstruire le problème de l’ingénierie logicielle et d’autres, les outils, les techniques et d’autres solutions susceptibles, à leur avis, de l’améliorer. Les participants divisés selon ces lignes ne pouvaient tout simplement pas s’entendre. Les idéalistes et les réalistes ne savaient pas comment collaborer et le centré sur le problème passait trop de temps à critiquer les solutions des personnes centrées sur la solution, tandis que les personnes centrées sur la solution étaient réticentes au retour. J'ai suggéré que nombre de ces divisions existaient encore dans la recherche actuelle en génie logiciel et j'ai remercié Brian d'avoir contribué à éclairer les origines historiques de ces divisions.

Ivar ouvre son discours avec une histoire.

Ivar Jacobson, un contributeur majeur à UML et au Rational Unified Process, a donné une conférence intitulée "50 ans d'ingénierie logicielle, alors maintenant quoi?". Il a commencé par une anecdote sur l'un de son premier projet d'ingénierie logicielle, où il a dû admettre , il ne savait rien du génie logiciel. Et pourtant, il a toujours dirigé l'un des produits suédois les plus réussis de l'histoire. Son interprétation du succès des logiciels est finalement due aux modèles commerciaux et aux développeurs, et non aux logiciels, et non aux processus. Son point de vue est qu’après 50 ans, il s’agit encore plus d’un métier que d’une discipline de l’ingénierie. En fait, dans l’histoire, il soutient que nous sommes beaucoup plus motivés par la mode que par la science: l’orientation objet, UML, CMMI, Agile, et tout ce qui va suivre, ont été et seront tous à la mode. L’argument d’Ivar était que toutes les guerres de méthodes étaient des distractions. Le véritable problème, selon Ivar, est que les méthodes sont en réalité des compositions de pratiques et que les méthodes sont monolithiques et emprisonnées dans des prisons gardées par des gourous. Pour Ivar, c’est immature et stupide.

Sa recommandation était de se concentrer sur la recherche d'un terrain d'entente sur les méthodes, les méthodes de modularisation et les pratiques libres à partir de méthodes. Il a parlé d'un organisme de normalisation prévoyant une notion de pratiques comportant des activités répondant à certains critères de réussite et de produits de travail issus d'activités évaluées par rapport à ces critères de réussite. Son point clé, cependant, est que tout cela nécessite que les développeurs soient compétents dans tous ces domaines. Les critères de réussite se résument aux besoins du client, à la solution produite et à une équipe chargée de la réaliser. Il a présenté plusieurs autres détails sur les états que l’on passe dans son modèle. Ce qu'il m'a décrit ressemble à une théorie scientifique du processus et à un ensemble d'idées de processus dérivées de cette théorie; quelque chose à tester et à raffiner, pas à l'évangile. En fin de compte, il l'a en réalité qualifiée de théorie descriptive et a appelé les chercheurs à la développer davantage en une théorie prédictive et explicative.

Immédiatement après la conférence d’Ivar, j’ai prononcé mon discours sur le prix du papier le plus influent de l’ICSE. Au milieu d'une séance de remise des prix, je pouvais dire que les gens étaient fatigués et prêts pour la fin de la semaine. Mon discours avait un ton sombre et réfléchi, mais un ton encourageant, et bien que le silence qui s’ensuivit ait été assourdissant, le bavardage sur Twitter était revigorant, montrant une communauté qui croit vraiment et valorise ce que j’avais à dire et qui a soif de conseils comment faire.

Andreas commence son discours

Andreas Zeller a parlé immédiatement après moi après avoir reçu son prix de recherche SIGSOFT. Il a raconté trois histoires sur sa carrière, toutes axées sur l'impact. La première histoire concernait son premier projet et sa première présentation dans lesquels il avait proposé une solution à la recherche d'un problème. Déçu par les retours, il a rebondi en se concentrant sur le débogueur GNU DDD, qui a eu un réel impact pratique. Sa première épiphanie était que trouver de vrais problèmes était si essentiel, mais aussi un excellent moyen d'avoir un impact. Sa deuxième histoire portait sur la simplicité. Quelqu'un lors d'une conférence était dégoûté de voir que son idée du débogage delta était si simple. Cela a conduit au syndrome de l'imposteur, un sentiment d'infériorité intellectuelle. Mais il s'est rendu compte au fil du temps que la simplicité était le pouvoir; la complexité était un échec. Sa dernière histoire portait sur le travail qu’il avait commencé avec Tom Zimmermann sur les référentiels de logiciels d’extraction. Il a observé que les craintes concernant les résultats de leurs premiers travaux n’avaient tout simplement pas d’importance, car c’était le fait que ces travaux étaient nouveaux. L'innovation consiste à étudier les régions obscures mais pertinentes du monde, peu étudiées. En fin de compte, Andreas a fait valoir que la seule chose qui compte vraiment, c'est l'impact. Il a conclu avec un appel inspirant à poursuivre nos rêves et à persister.

Dire au revoir à Göteborg, il est difficile de résumer tout ce que j’ai appris lors de l’ICSE de cette année. Mais essayons quand même:

  • En fin de compte, nous sommes tous dans cette communauté pour améliorer les logiciels. Concentrons-nous sur cela, pas sur des mesures à court terme.
  • Nous avons besoin d'idées plus grandes, probablement sous forme de théories, pour nous guider et guider notre impact.
  • Nous devons penser à la pertinence, et non au caractère publiable, pour atteindre les objectifs ci-dessus.
  • Nous ignorons les facteurs humains du génie logiciel à nos risques et périls.

Ce sont des leçons que chaque membre de notre communauté doit finalement intérioriser. Cela fait 50 ans que nous avons compris leur importance, et nous commençons tout juste à les prendre au sérieux.