Plus loin que la simplicité : la rusticité

J’ai déjà parlé du concept de simplicité sur ce blog. J’espère que tout le monde est convaincu des avantages que cela procure à tous les niveaux :

  • Une interface simple sera plus facile à comprendre et à utiliser ; elle sera plus ergonomique.
  • Un code simple sera plus facile à corriger et à faire évoluer ; il sera plus facile à maintenir.
  • Une procédure ou une méthode sera adoptée d’autant plus rapidement qu’elle sera simple à appréhender et facile à mémoriser.

Nous sommes d’accord, le «simple», c’est bien. Et comme d’habitude, c’est aussi le moment de dire que le «simpliste», ce n’est pas bien. Faire quelque chose de simpliste, c’est lorsqu’on recherche la simplicité aveugle ; quand on confond «en faire moins» avec «en faire le moins». Il faut parfois complexifier un peu un programme pour en simplifier l’ergonomie. Ou faire des concessions sur la simplicité d’une procédure si cela peut en augmenter l’efficacité.

Bref. Ce dont je veux vous parler aujourd’hui, c’est du concept de rusticité.

L’un des fondements du travail d’informaticien, c’est d’aimer la technologie, de se passionner pour l’avant-garde du high-tech, de chercher à connaître les technos du futur. C’est ainsi qu’on cherchera à mettre en œuvre des concepts ou des briques logicielles (ou matérielles) que nous ne maîtrisons pas forcément, pour le plaisir d’apprendre à les utiliser. Souvenez-vous ce que je disais sur la R&D : il ne faut pas confondre développement et veille technologique.

Sans aller jusqu’à faire de la recherche alors qu’on devrait faire du développement, on peut conduire nos choix en se laissant porter par des effets de mode. Quelle est la techno «hype» du moment ? Quels sont les derniers «buzzwords» à connaître ?

En entreprise, les facteurs qui conduisent à un choix technologique sont multiples. La stabilité et la pérennité sont très importants. Ils le sont souvent plus que la performance ou le coût.
Ajoutez cela à la simplicité, et vous aboutissez à la «rusticité».

Une techno rustique, c’est quoi ?

Attention à ne pas comprendre de travers ce que j’essaye d’expliquer. Je ne suis pas en train de dire qu’il faut systématiquement utiliser des technologies antédiluviennes, au nom de leur rusticité. Moi je parle de “rusticité high-tech”, si je puis dire 🙂

Prenons un exemple au sujet des langages de programmation :

  1. Coder un site web en Fortran, ce n’est pas rustique, c’est débile. Votre site sera difficile à maintenir, vous aurez du mal à trouver des développeurs Web compétents dans ce langage, vous n’aurez aucun gain de performance par rapport à d’autres langages, et il vous manquera l’accès à un certain nombre de librairies très utiles.
  2. Par contre, une application de calcul scientifique distribuée sur un cluster pourra être codée en Fortran. C’est un choix très répandu : C’est un langage sans allocation dynamique, donc qui s’optimise très bien sur les architectures distribuées ; de nombreux scientifiques continuent à maintenir du code écrit en Fortran il y a 30 ans, sans avoir objectivement besoin de changer de langage ; réutiliser ce code est une bonne idée.

Un exemple concernant l’innovation fonctionnelle :

  1. Depuis la première version de Microsoft Word sous Windows, l’ergonomie générale des logiciels de traitement de texte WYSIWYG a finalement peu évolué, si on la compare aux changements technologiques qui sont intervenus dans leurs entrailles.
  2. Lorsque le logiciel ICQ est sorti en 1996, c’était une révolution du point de vue des fonctionnalités qu’il proposait. Il a créé les messageries instantanées. L’IRC existait déjà, permettant à des utilisateurs de discuter entre eux en temps réel, au sein d’espaces numériques partagés. L’email existait aussi, permettant à une personne d’envoyer des messages à une unique personne. Mais ICQ offrait la possibilité de se constituer une liste d’amis, de voir leur statut de connexion en temps réel, et d’instancier des discussions personnelles avec chacun d’eux. Pourtant, d’un point de vue technologique, il s’agit là d’une application client-serveur particulièrement basique.

Quelques autres exemples :

  • Une société française, éditrice d’une solution de sauvegarde en réseau, a besoin de porter son logiciel serveur sur un très grand nombre de plate-formes. Ce logiciel contient une base de données. Plutôt que d’implémenter une solution complexe, les données sont stockées dans une arborescence étudiée sur le système de fichiers. Les répertoires servent d’index. Le seul problème, facilement gérable, est que cela peut potentiellement consommer un grand nombre d’inodes. Mais à part ça, c’est une solution simple, performante et très stable, supportée de la même manière sur tous les systèmes Posix. Pourquoi réinventer la roue, alors que les systèmes de fichiers font partie des choses les mieux optimisées dans les kernels ?
  • Google a sorti son navigateur Chrome il y a deux ans. L’une des “grandes avancées” de ce navigateur était le fait qu’il utilise un processus séparé pour chaque onglet, au lieu d’utiliser un thread au sein du même processus. On est en plein dans le rustique : Faire un fork() pour créer un nouveau processus, ça existe depuis la nuit des temps ; par contre, on enseigne que les threads sont moins gourmands en ressources, plus rapides et plus souples, et ils sont donc présentés comme étant la solution de choix quand on veut faire des traitements parallèles. Sauf qu’on a tous vu un jour un navigateur se planter tout entier, juste parce que l’un des onglets contenait un plugin qui est parti en erreur. Le choix du multi-processus au détriment du multi-thread, c’est un choix rustique mais très intelligent.
  • Dans le domaine des appareils portables (téléphones, smartphones, PMP, …), un des enjeux majeurs concerne les écrans. Chaque constructeur essaye de mettre au point des écrans qui soient lisibles, contrastés, lumineux sans être fatiguant pour les yeux, réactifs et bons marchés. Dans ce domaine, les nouvelles technologies pleuvent : IPS, AMOLED, Super-AMOLED, Super-LCD, E-Ink, Mirasol, Pixel Qi, … Mais des appareils se préparent à déferler sur le marché, équipés d’écrans « C-Paper » qui reprennent une technologie éprouvée, remise au goût du jour, et dont le rapport qualité/prix semble particulièrement bon (voir cette chronique sur le site Blogeee). C’est le genre de chose qui peut faire la différence dans un univers high-tech ultra-compétitif.
  • Dans les années 90, et jusqu’au début des années 2000, l’informatique lorgnait du côté de la reconnaissance d’écriture et de la reconnaissance vocale. Le Newton d’Apple, puis le Palm Pilot et les PocketPC reposaient tous sur un principe qui semblait alors naturel : pour communiquer avec la machine, écrivons dessus avec un stylet. Cela a fonctionné plus ou moins bien. Pareil pour les logiciels IBM ViaVoice et Dragon Dictate, qui nous proposaient de commander nos ordinateurs à la voix. Qui le fait aujourd’hui ? De nos jours, les smartphones se commandent au doigt − le stylet à disparu − et les textes y sont tapés sur des claviers virtuels. C’est moins futuriste, mais ça fonctionne beaucoup mieux. Et si la reconnaissance vocale s’y intègre chaque jour un peu mieux, on reste sur des usages de niche (traduction, aide aux handicapés) éloignés des promesses passées.

Et concrètement ?

Dans le quotidien d’un informaticien, la rusticité revêt de nombreuses formes, mais repose toujours sur 3 aspects :

  1. Simplicité : Tout à déjà été dit à ce sujet, non ? Supprimez l’inutile, gardez l’essentiel.
  2. Stabilité : Privilégiez les solutions éprouvées, dont les qualités ont été vérifiées au fil du temps, et qui resteront valables plus longtemps que la durée pendant laquelle vous en aurez − a priori − besoin.
  3. Connaissance : Privilégiez les solutions que vous maîtrisez. Ne faites pas confiance (à une techno, un choix fonctionnel ou autre) si vous êtes totalement néophyte sur le sujet. Quand vous serez monté en compétence et que vous aurez fait des prototypes, vous pourrez alors envisager d’y aller ; mais pas avant.

Alors je ne peux que vous conseiller de garder tout cela à l’esprit, ça pourra vous servir.

9 commentaires pour “Plus loin que la simplicité : la rusticité

  1. Amusant, je viens d’écrire un bout de code (ou je delete des lignes de deux tables liées par une FK) avec gestion de la transaction en cas d’erreur etc…
    50 lignes de codes pour ce truc tout simple.

    Et puis je regarde le code et je me rend compte qu’en fait, je me fous totalement de pouvoir faire un rollback si l’opération echoue, je peux carrément vider les deux tables et recommencer (pour faire simple).

    Le code prend maintenant 10 lignes.

    Keep it Simple.

  2. « […] Quand vous serez monté en compétence et que vous aurez fait des prototypes, vous pourrez alors envisager d’y aller ; mais pas avant. »

    C’est là toute la difficulté de l’informatique.
    On ne maitrise un technologie que lorsque l’on a eu des projets concrets et fait des erreurs.

    A mon avis, il faut savoir prendre des risques. Appelons ces risques : Challenges 😉

  3. @Loïc : On est d’accord. Et si tu as une douzaine de fonctions dont la taille est divisée par 5 de cette manière, le développeur qui devra intervenir sur ce code dans 6 mois pourra faire son boulot efficacement, au lieu de patauger dans des trucs difficiles à comprendre.

    @Thomas : Pas d’accord. En entreprise, les projets sur lesquels on travaille ont des objectifs (de calendrier, de qualité, de coût) qui font que ce n’est pas au moment où on travaille dessus qu’il faut réfléchir à l’apprentissage de nouvelles technologies. Ça, c’est de la R&D.
    Que le client soit interne ou externe, il n’acceptera jamais des retards ou des dépassements de budget, juste parce qu’on a eu envie de tester des technologies « funky ».

    Évidemment, la frontière est un peu floue. Même sur des choix stables et bien connus, on va gagner en compétence et/ou on va devoir mettre en place certaines nouveautés à la marge du projet.

    Mais quand un de mes développeurs arrive en me disant :
    «J’ai envie de connaître RubyOnRails/JEE/Zope/…, est-ce que je peux l’utiliser sur mon nouveau projet ?»
    Je lui répondrai invariablement :
    «Non. On va continuer avec nos technos habituelles, parce que les projets de l’entreprise doivent être planifiable et maintenables. Il nous faudra vivre avec, former chaque nouveau développeur à cette techno, le maintenir le jour où tu quitteras l’entreprise… Par contre, réfléchissons à un side-project qui pourrait être intéressant.»

  4. il y a effectivement des choix technologiques qui semblent rétrogrades voire antédiluviens et qui pourtant remplissent parfaitement le besoin initial …
    exemple :
    – nous devions recevoir quotidiennement des données d’un partenaire pour les insérer dans notre BDD, de manière synchrone … webservice XML, SOAP, BPEL, JOLT ? Qui allait développer tout ça ? Finalement, un simple « sendmail » fait parfaitement l’affaire !

  5. Oui, c’est un bon exemple. Chez nous, quand on doit envoyer des données vers un autre système d’information, on évite le XML-RPC ou le SOAP, on envoie tout simplement les données en POST. Il n’y a pas plus rapide à mettre en place de l’autre côté.

    D’ailleurs, il suffit de voir que les techniques REST ont peu à peu remplacé le SOAP, qui lui-même a remplacé le CORBA. Sincèrement, aucun fournisseur n’implémente complètement Corba 3, tellement c’est complexe. Pourquoi vouloir toujours faire compliqué alors qu’on peut faire simple ?

  6. Chez moi on ne fait pas du web mais des systèmes embarqués en grande série (des millions de pièces), et donc les décisions techniques sont très influencées par les achats. Une nouvelle technologie (un nouveau processeur par exemple) peut donc être choisi, tout simplement parce qu’il est moins cher que celui qu’on utilisait avant, plus ‘rustique’ mais maîtrisé… Les choix les plus simples pour le logiciel ne sont pas forcément ceux de la logique de l’entreprise – surtout dans l’industrie…

  7. Je ne suis pas sûr de comprendre ton point, Raf. J’ai l’impression que tu veux dire que l’aspect « rustique » n’est pas un critère de choix dans ton domaine, mais j’ai aussi l’impression que l’utilisation de matériels connus et éprouvés (et donc « rustique », à mon sens) reste quelque chose d’important.

  8. Je suis d’accord avec tes arguments, privilégier les solutions simples et éprouvées.
    Dans ton article tu donnes des exemples de choix risqués non justifiés : technos « sexy »ou tendances « hype » qui n’apportent rien fonctionnellement à l’utilisateur final.
    Je fais le parallèle dans mon domaine où l’entreprise fait des choix sur des critères qui me font prendre des risques sans que l’utilisateur final voit une différence. La solution simple ou rustique pour le logiciel n’est pas forcément celle que choisi l’entreprise. Il faut donc aussi savoir s’adapter à la complexité, on ne peut pas malheureusement toujours faire aussi simple qu’on le voudrait.
    Bien sûr, ça dépend fortement du contexte et des cultures métiers, c’est pourquoi je décris ce qui se passe dans mon univers un peu différent du tien.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.