Les abstractions permettent d’avoir moins à savoir
Lorsqu’on utilise un cadre de programmation maintream, par exemple un langage de programmation grand public et une base de données SQL, de nombreuses abstractions nous facilitent la vie : systèmes d’objets, SQL ou ORM, sockets réseaux…
Ces abstractions permettent de simplifier le modèle mental nécessaire à développer, mais peuvent aussi permettre de ne pas avoir à connaître le fonctionnement des couches qui ont été abstraites.
Ainsi, en général il n’est pas nécessaire de comprendre la manière dont un OS gère ses pages mémoire pour écrire une application web.
Alors que les différentes couches “masquées” sont de plus en plus complexes, cela permet qu’au contraire le développement demande de moins en moins de connaissances sur ces “autres” sujets.
Le risque de la dette d’apprentissage
Le problème est quand ce modèle coince et qu’on se retrouver en face d’une “dette d’apprentissage”. Quand on a pu — jusque là — faire l’économie de comprendre le fonctionnement de certains éléments, mais que ça n’est plus le cas.
Soit parce qu’on a besoin d’implémenter quelque chose alors que vos connaissances ne le permettent pas, ou pire, qu’un bug dans une des abstractions a fait planter vos serveurs de production.
Peut-on espérer le salut ?
Ce problème est parfois mentionné dans les article sur le bloat de l’informatique moderne, c’est-à-dire qu’à force d’empiler des couches, chacune introduisant de l’inefficacité, l’augmentation de puissance des machines ne se traduit pas par une augmentation de rapidité mais au contraire par une augmentation du gaspillage.
Mais je ne pense pas que les choses vont changer dans ce domaine d’une manière significative même si de nouveaux OS comme Android peuvent permettre de supprimer quelques couches.
Par contre ce qui s’améliore avec le temps c’est la qualité des abstractions, c’est-à-dire que l’empilement des couches sera plus harmonieux et produira moins de cas limites générateurs d’imprévus.
Que faire ?
La meilleure solution est bien entendu de disposer de la connaissance dont on peut avoir besoin suffisamment à l’avance pour ne pas être bloqué.
Ce qui suppose de savoir à l’avance de quoi on va avoir besoin et de quand cela va se produire.
Avec de l’expérience on peut arriver à déterminer les zones “chaudes” qu’il y a besoin de connaître. Il s’agit alors de s’assurer d’avoir les bonnes compétences sous la main, même si elles ne servent pas tous les jours. C’est une des raisons d’avoir dans ses équipes des ovins à 5 pattes.
Plus votre organisation est grande, plus il est facile d’entretenir un “pool” large de connaissances sur les différentes briques et donc d’avoir un risque plus faible. C’est d’autant plus vrai qu’une organisation plus grande signifie souvent besoins plus complexes et ces connaissances sont dans ce cas utilisées et pas seulement nécessaires “au cas où”.
Pour réduire le risque on peut aussi limiter le nombre de technologies pour réduire les compétences à maîtriser. Cela peut faire grincer des dents, mais c’est à mettre en rapport avec les conséquences en cas de problèmes.
L’autre approche est de transférer le risque, c’est-à-dire de faire en sorte de se reposer sur la connaissance de quelqu’un d’autre. La manière historique de le faire est d’acheter du support pour les logiciels, c’est-à-dire de payer pour avoir la capacité d’appeler quelqu’un quand il y a un problème : l’empilement est toujours là mais vous n’êtes pas seul·e face à lui.
Une autre manière correspond aux offres cloud comme le serverless, qui consistent à payer pour un service qui masque les couches dans une boite noire.