D’Ada Lovelace, chaînon manquant entre Babbage et Turing, au coût des projets

Je ne sais pourquoi mais, comme moi, vous avez dû voir fleurir ce printemps les posts et articles sur Ada Lovelace.

Je vais apporter ma contribution à cette floraison car cette mère poétesse de la programmation informatique a croisé très tôt mon parcours. En effet, ce fut ma prof d’assembleur à l’IUT d’Orsay qui me parla pour la première fois d’ADA en 1987. Ses notions de parallélisme et de contrôle strict de la modularité m’ont tout de suite séduit. L’évolution de ce langage vers le temps réel et la programmation par contrat ne m’ont pas détourné de celui-ci, bien au contraire.

De fil en aiguille, les articles publié sur Ada Lovelace et sur le langage qui a pris son nom, font resurgir ma réflexion sur l’équilibre entre la rigueur du coding et le coût de la programmation dans la création d’un programme informatique. En effet, choisir un langage c’est déjà choisir un coût de production et la phase projet ou l’effort principal va  devoir être fourni : coding ou recette ?

Pour les lecteurs pressés voici un sous-menu de l’article : Ada Lovelace, ADA, Coût d’un projet

Mais revenons en à l’inspiratrice du langage :

Ada Lovelace (1815-1852) 1 ère Programmatrice mais pas que…

Je ne vais pas ici refaire la biographie d’Ada Lovelace, fille de Lord Byron, que l’on peut retrouver sur wikipedia : https://fr.wikipedia.org/wiki/Ada_Lovelace. Mais je vais plutôt vous aider à découvrir cette femme méconnue, pour ne pas dire oubliée, qui a pourtant contribué à la naissance de l’informatique moderne. Pour cela, j’insisterai sur certains traits de son parcours avec à quelques liens.

Résumé lyrique en 3mm44

Tout d’abord, ceux qui n’ont pas beaucoup de temps, pourront visionner cette vidéo récente de France culture et l’article consacré à Ada Lovelace (https://www.franceculture.fr/numerique/ada-lovelace-la-premiere-codeuse-de-lhistoire ).

Résumé factuel

En résumé, Ada Lovelace, est donc :

• Femme scientifique dans un monde d’hommes.
• Mathématicienne mais fascinée par la poésie (héritage de son père malgré l’opposition de sa mère).
• Elle écrit à 27 ans l’enchaînement d’instruction qu’il faut donner pour réaliser une suite mathématique . En cela elle définit  le premier programme et presque la première architecture machine (que l’on attribue plutôt à  AlanTuring 100 ans plus tard). Ainsi elle invente :
  • Le « Store » : colonne de la data, origine de la mémoire ;
  • Le « Mill » : colonne du calcul central, origine du CPU ;
  • La boucle ou répétition d’une partie du code, origine de nos while, until et for next ;
  • La condition, origine de nos if et case of.
• Elle est la première à avoir la vision de calculateur universel ou de machine computationnelle permettant de traiter aussi bien l’algèbre que les actions.

En résumé, je reprends cette phrase de Nicolas Witkowski, physicien interviewé dans l’émission « La Marche des sciences » de France Culture (Cf. ci dessous), consacrée à Ada Lovelace  :

« Ce qu’elle cherche, c’est plus une métaphysique qu’une science ou une technique. Une façon de vivre. À un moment, elle propose d’utiliser son propre corps comme laboratoire moléculaire. Non seulement elle anticipe l’informatique et l’ordinateur, mais elle anticipe les neurosciences quelque part ». 

1h de podcast pour aller plus loin

Ensuite, ceux qui ont un peu plus de temps et qui veulent comprendre la façon dont Ada Lovelace étudie la machine des différences puis la machine analytique ou universelle de Charles Babbage, pourront écouter ce podcast plus ancien de France culture  :

https://www.franceculture.fr/emissions/la-marche-des-sciences/ada-lovelace-lady-de-l-informatique

Bref une femme méconnue peut-être même de Von Neumann et Turing , pré-histoire de l’informatique, et que l’armée américaine a eu l’intelligence de ressusciter en nommant son langage ADA

Pourquoi ADA est-il un langage à part ?

Là encore je ne vais pas reprendre l’historique et les caractéristiques du langage. Wikipedia le fait très bien : https://en.wikipedia.org/wiki/Ada_(programming_language).

Et je ne ferai pas non plus un tuto car ceux qui voudront apprendre ADA pourront très bien suivre le cours d’open classroom : https://openclassrooms.com/fr/courses/900279-apprenez-a-programmer-avec-ada. Mais je vais plutôt reprendre et insister sur quelques caractéristiques du langage.

En premier lieu sachez que c’est un langage compilé et non interprété.

Un langage fiable

Réf: “An Empirical study of Programming Language Trends”

Ada a été commandité par l’armée américaine suivant un cahier des charges insistants sur le fait de fiabiliser les développements et d’en diminuer les coûts.

Pour cela un certain nombre de règles y contribuent fortement :

• Un typage des variables statiques nécessitant des conversions explicites ;
• Un langage verbeux, claire, non ambiguë et normalisée facilitant la lecture / relecture de code ;
• La notion de module ou package dont l’empaquetage est sécurisé ;
• Une programmation par contrat permettant de définir les conditions pré-opératoire et post-opératoire ;

La fiabilité du langage est donc ici assurée avec une plus grande prise en charge :

•  des erreurs humaines par :
  • la limitation des implicites ;
  • la facilitation de la compréhension
• des erreurs de condition d’exécution par la programmation par contrat
• des tests par la modularité du code.

Un langage temps réel

Ada à la particularité de prévoir :

• multi-tâche et le parallélisme
• le temps réel avec les priorités, l’interruption, l’objet protégé, le profil Ravenscar…
• l’interfaçage avec les autres langages

Et bien évidemment les autres paradigmes dont ceux de la POO

Ada comporte de nombreux paradigmes plus communs aux autres langages comme :

• Les pointeurs
• La récursivité
• Un véritable langage de programmation orienté objet avec héritage, dérivation, polymorphisme
• La programmation événementielle avec GTK

Utilisation d’ADA

Au final, ADA est un langage de niche très utilisé dans le temps réel et l’aérospatial.

Et pour en savoir plus sur ADA

Pour ceux qui veulent aller plus loin sur Ada voici quelques liens :

• Le petit catalogue des ressources ADA sur le net d’Adalog (société) : http://www.adalog.fr/fr/adaweb.html et les publications de son fondateur en français : http://www.adalog.fr/fr/publications.html#complete  et en anglais : http://www.adalog.fr/en/publications.html
•  les documents normatifs : https://www.adaic.org/
• les ressources de l’association française ADA : https://www.ada-france.org/adafr/ressources.html
• Ce court de l’école polytechnique de Montréal: http://www.groupes.polymtl.ca/inf6300/ et son pdf d’introduction : ADA – polytech canada – Seance2_inf6300
• Et bien sur : http://www.ada2012.org/

ADA me fait réfléchir sur les coûts du code

https://theonlineadvertisingguide.com/glossary/roi/

Tout cela pour en arriver à trois réflexions sur nos pratiques du développement :

• L’anticipation du bug pour en limiter le coût
• Le ROI du coding : l’investissement dans la norme de coding
• Le développement au regard de la finance : CAPEX-OPEX & TCO

L’anticipation du bug

Certaines phrases raisonnent en vous comme des maximes de vérité sans jamais avoir été démontrées. Je ne me souviens plus quel enseignant, car cela ne peut être qu’un prof, m’a inculqué la phrase ci dessous, mais elle raisonne en moi à chaque projet et résume assez bien mon état d’esprit et finalement celui de beaucoup de méthodologies de développements actuels.

« Il faut 1 heure pour corriger un bug trouvé au développement et 80h si le bug est trouvé à la recette »

https://watirmelon.blog/2013/05/17/fixing-bugs-in-production-is-it-that-expensive-any-more/

ADA, comme nous l’avons vu est fiable pour de multiples raisons et diminue le temps de développement. Mais ADA est un langage de niche peu utilisé.

Pourtant aujourd’hui, nos méthodologies de développement multiplient les efforts et donc les coûts pour limiter les bugs en amonts de la recette.

Ainsi la mise en place des T.U., les chaînes d’intégration continue puis de continuous delivery a amélioré la vitesse de production et diminué les bugs de régression . Et les méthodologies agiles et Scrum ont diminué les bugs fonctionnels d’inadéquation entre le logiciel produit et le besoin de l’utilisateur final. Enfin les TDD limitent les bugs et intègrent le test comme étant le guide du développement…

Ne faut-il pas aussi en revenir, y compris sur des langages peu stricts comme php ou souples dans leur notification comme C à des principes de base, en s’imposant des normes de coding stricts à respecter ?

Bien souvent cette question n’est posée qu’en fonction de l’échelle du projet. Mais ne peut-elle pas être simplement incluse à tous les projets ?

Cette norme de coding peut-elle être universelle? A l’échelle d’une entreprise?

Le ROI du Coding

La rigueur d’un langage comme ADA, impose une norme à la formation de celui-ci. Elle n’est donc pas à la charge du projet mais peut être à la charge de l’entreprise s’il s’agit de former les IED au langage.

Cette norme est bien souvent hybride entre l’entreprise ou l’équipe (la culture d’entreprise) et le projet… En effet, les enjeux d’un projet : transaction financière ou pas, risque juridique,… ont un impacte sur la quantité de normes que l’on va mettre en place. C’est aussi ce que l’on fait lorsque l’on défini le « fini » en méthodologie Scrum.

Mais ainsi, le coût de cette norme fluctuante de coding d’un projet à l’autre est chère car il faut comptabiliser :

• sa définition : il faut le redéfinir à chaque projet ;
• la formation : il faut former l’équipe à cette norme ;
• l’apprentissage : pour qu’une norme soit respectée il faut la contrôler, la faire respecter et donc corriger ce qui ne la respecte pas ;
• les frais de contradiction : dans le cas d’équipe, peut-être international (offshore),  travaillant en parallèle, les normes peuvent être différentes et se contredire…

Au bout du compte, la question qui se pose est celle de l’investissement que l’on veut accorder au coding et en cela le retour sur investissement que l’on attend…

Le développement au regard de la finance

Au regard de la finance, développer un programme doit respecter deux choses :

• Avoir un retour sur investissement c’est à dire gagner plus avec le produit fini que ce que l’on a dépensé pour le réaliser
• Maximiser le ROI c’est à dire diminuer au maximum les coûts, et donc les méthodologies préventives de diminution des bugs, sans prendre « trop » de risque au regard des enjeux de chaque projet.

Pour cela il faut chiffrer le coup de création d’un logiciel (CAPEX) au regard :

• de la méthodologie utilisée ;
• de son architecture applicative ;
• du temps de développement ;
• de sa recette et de sa validation ;
• de son déploiement
• mais aussi :
  • en fonction du coût de la technologie utilisée (un dev ADA est plus chère qu’un dev php)
  • en fonction  des normes de coding que l’on va fixer
  • de la conduite du changement généré par l’UX/UI prévue
  • le coût de transition (migration de données)

Pour un DSI sa réflexion va aller plus loin. Il doit anticiper les coûts d’OPEX annuels en prenant en compte :

• les frais de maintenance des matériels d’hébergement de l’application
• les frais de maintenance applicative qu’elle soit corrective, préventive ou évolutive
• les frais d’intégration d’un nouvel employé

Enfin il fera intervenir la durée amortissement (AM) ou de vie de l’applicatif pour en calculer le TCO = (CAPEX + (AM*OPEX))

En guise de conclusion

Le manager en charge d’un projet doit comprendre l’impact économique de chaque décision qu’il prend sur un projet afin d’en déterminer les impacts sur le TCO. Pour cela il doit aussi parfaitement comprendre et intégrer l’objectif métier d’un projet, surtout s’il s’agit de digitalisation de processus, afin d’intégrer la notion d’amortissement et de gain financier de l’application produite.

Comme Ada Lovelace, mathématicienne, pouvant inventer la programmation, il faut avoir une part de poésie ou plutôt de vision de l’avenir, une métaphysique du projet, pour mener à bien fonctionnellement et économiquement un projet de digitalisation.