Faiblesse des abstractions

Joel Spolsky (encore lui) a écrit il y a longtemps The Law of Leaky Abstractions, et je viens seulement de découvrir ce texte long mais limpide sur un aspect essentiel de mon travail de développeur. Citations marquantes et renchérissement personnels...

Une abstraction est une chose courante en développement logiciel. En informatique, plus largement. Dans la vie, en fait, Joel le démontre aisément.

On commence par une mauvaise nouvelle

All non-trivial abstractions, to some degree, are leaky.

Basiquement une abstraction masque une certaine complexité, et donc face à un monde réel il arrive qu'un jour l'abstraction laisse voir une faille, et laisse "fuir" un peu de cette complexité masquée.

Une anecdote personnelle : j'ai enseigné comment utiliser mon CMS à quelques personnes. Ce logiciel a pour but d'abstraire toute la connaissance du HTML et la difficulté à gérer un site de manière cohérente. La plupart des problèmes viennent quand la réalité reprend ses droits et qu'elle ne peut être gérée par l'outil. L'utilisateur est alors perdu.
Remplacez le "HTML" par "un ordinateur", "mon CMS" par "une interface informatique quelconque", et vous avez le même schéma : tant qu'aucun incident ne se produit, tant que l'utilisateur reste dans la logique du concepteur, tout marche bien. Que l'on mette en pied en dehors, et il faut avoir un BAC+2 en informatique pour s'en sortir.

Et en conclusion

So the abstractions save us time working, but they don't save us time learning.

C'est diablement vrai, et c'est peut être ce qui rend l'embauche d'un développeur si difficile, comme il est dit dans l'article : il faut s'assurer qu'il connaît les outils nécessaire et surtout qu'il sait faire sans en cas de besoin...

Selon la logique non-aristotélicienne évoquée dans le cycle du non-A de Van Vogt

La carte n'est pas le territoire

Le billet de Joel en est une bonne illustration.