Ou est ma place dans cette usine ?

Parfois, je lis des analogies hasardeuses entre fabriquer du code et fabriquer des voitures ou des buildings.

“C’est compliqué”.

Alors si c’est ça le critère, c’est aussi très compliqué (pour moi en tout cas) de réussir une tarte au citron.

Non, le critère tient plutôt à la ressemblance des méthodes de production.

Quelle ressemblance ?

Dans le monde de la brique et du mortier, il y a des ingénieurs qui conçoivent des trucs. Il en font des plans détaillés et des modes opératoires à destination d’autres personnes qui vont les exécuter.

Ensuite, des opérateurs de production vont fabriquer le produit fini : une voiture, un avion, un immeuble.

Ce découpage a fait ses preuves.

Et il faut bien reconnaître que les méthodes industrielles ont bouleversé la production dans la seconde moitié du 20ème siècle.

Les principes élaborés chez les industriels de l'automobile il y a 60 ans sont encore largement utilisés pour :

améliorer la qualité et la fiabilité des produits,
en diminuant le coût de production,
mais en augmentant les possibilités de personnalisation.

Alors c’est tentant.

Tentant de décliner ces méthodes à "l'industrie du logiciel". Pour faire des "code factory".

Et ça n’a pas bien marché.

Ou sont les devs ?

Dans son excellente conférence “Entre industrialisation et artisanat, le métier de développeur” (cf lien à la fin), Arnaud Lemaire pose la bonne question :

Ou se situe le développeur ?

A l’apogée de l’ingénierie logicielle (qui se souvient de Merise ?), on a tenté de découper le cycle du développement logiciel en copiant l’organisation industrielle :

des architectes, analystes, ingénieurs ... qui conçoivent et spécifient,
des développeurs qui codent ce qui est spécifié, comme un opérateur de chaîne de production,
des contrôleurs qualité qui vérifient la conformité de ce qui est codé.

A posteriori, une sorte de fiasco quand même.

Pourquoi ?

Parce que le développeur n’est pas à la bonne place.

Parce que le code source n’est pas le produit.

Si c’était le cas, je livrerais seulement à mes clients un gros paquet de code source sur un listing avec la satisfaction du devoir accompli.

Mais mon client se fiche de mon code source. Ce qui importe, c’est que le site soit en ligne, que l’app mobile s’exécute sur le smartphone, ou que la voiture autonome avance toute seule sans accident.

Le code source, c’est le plan. C’est la documentation.

De la documentation qui compile en quelque chose d’exécutable sur une machine.

Et donc l’usine, la chaîne de production, c'est quoi ?

C’est le compilateur, le bundler, le transpileur, le linkeur ... Bref tous ces outils qui transforment les plans (=le code source) en un produit.

Nos Dockerfiles et Makefiles décrivent l’usine.

Une usine dans laquelle tout est automatisé. Pas besoin d’opérateur de chaîne de production (hormis quelques Ops pour surveiller que tout va bien).

Et les développeurs dans tout ça ?

Et bien ce sont eux les concepteurs.

De codeur à concepteur.

Je sais que ça donne un peu le vertige. Surtout aux développeurs qui devront s'acheter une cravate.

Le concepteur, c’est celui ou celle qui transforme une idée en un plan. Qui part de l’idée d’un avion pour élaborer le plan d’un avion.

J'observe que les démarches agiles visent à corriger cette erreur de placement. Elles ré-intègre le développeur dans son rôle de concepteur. Elles s'attachent à la compréhension de l'idée et au partage de la vision avec les développeurs.

Ce qui part en production, c’est ce que le développeur a compris.

Par contre, il semble y avoir un temps de retard du côté de la formation, qui n'a pas toujours bien intégré cette compétence de concepteur.

Par exemple, les promesses de reconversion en 3 mois vers le métier de développeur sont probablement vouées à l’échec, lorsqu’elles enseignent la syntaxe d'un langage au détriment de la conception.

Le plus important dans une doc ou un plan détaillé, ce n’est pas l’absence de faute d’orthographe.

Le plus important, c’est le plan. Avec des boites, des flèches et des mots.

Références :