Back to coding : le développement 20 ans plus tard, qu'est ce qui a vraiment changé ?
Après avoir dirigé une société de service informatique, me voici redevenu programmeur. C’est un parcours peu habituel, dont les enseignements méritent d’être partagés, à différents égards.
Une première réflexion porte sur la redécouverte de la programmation après une vingtaine d’années d’absence. Un peu comme on revient dans la ville où l’on a passé son enfance, après vingt année d’éloignement : on découvre un urbanisme transformé, des immeubles, des commerces, des signalisations qui n’existaient pas, et pourtant l’essentiel est encore là et l’on peut retrouver son chemin.
Dans cet univers en pointe où le changement est rapide et constant, qu’est-ce que l’on retrouve ?
De nouveaux langages de programmation sont apparus, mais aucun n’a révolutionné la programmation. Les langages proprement dits ne sont pas, à mon sens, la partie la plus déterminante de l’informatique et il est même étonnant qu’ils puissent susciter de telles guerres de chapelles.
Dans les 20 dernières années, le développement est devenu plus complexe. A moins que ce ne soit mon cerveau qui ne se soit affaibli... Alors que l’on travaillait souvent dans des environnements bornés, aux fonctionnalités limitées, essentiellement propriétaires, on travaille aujourd’hui en assemblant un plus grand nombre de librairies et de services, et il y a une complexité nouvelle à sélectionner, appréhender, et intégrer tous ces composants.
Le développeur “full stack” d’aujourd’hui doit maîtriser un langage de backend, une API SQL, et souvent une API NoSQL plus une API de search, HTML, CSS, Javascript, ainsi qu’un framework frontend, et quelques dizaines de composants qu’il aura trouvés sur Github ou ailleurs. Chacun de ces outils apporte productivité et (idéalement) robustesse, mais il est indéniable qu’il devient plus difficile de maîtriser tous les aspects d’une plateforme à l’état de l’art. Ce qui conduit à une plus grande taylorisation du développement, réunissant une diversité d’expertises.
Dans les années 90, un mouvement puissant poussait la programmation vers un développement totalement interactif intégré à des environnements graphiques : on disposait à la souris des composants d’interface dans une boîte de dialogue, puis on leur définissait des propriétés, et des méthodes si possible par un simple clic-droit, ou le choix dans une liste déroulante. L’idée était de masquer, voire d’éliminer, le code source, qui était généré mais si possible qu’on éviterait de manipuler en l’état.
Lorsque le développement d’applications s’est tourné vers le web, certains ont imaginé prolonger ce mouvement : des outils graphiques nous permettraient de poser des objets sur une page et d’en définir les propriétés, et le Html sous-jacent serait rendu invisible. Il est intéressant de constater que cette vision d’une programmation purement interactive a totalement été évacuée dans les 20 dernières années, et ne reviendra plus. L’informatique est redevenue essentiellement textuelle, alors même que les interfaces finales devenaient toujours plus graphiques.
Une autre chose frappante est que, malgré 20 années de loi de Moore, les performances restent un sujet essentiel. Dans certains cas, les gains obtenus côté processeurs ou disques sont dilapidés par les mauvaises habitudes prises par les développeurs tombés tous petits dans la marmite de la CPU pas chère. Au final, aujourd’hui comme hier, on ne peut éviter quelques compromis entre la beauté de notre modélisation et les temps de réponse.
Dans un prochain épisode, j’aborderai la question des outils de travail du développeur, et de leur coût tel qu’il est perçu par le dirigeant d’entreprise.