Commentaires sur : Devons-nous changer de paradigme pour le développement d’applications informatiques?

Par : Chantale Demers

Chantale Demers — Sun, 24 Jan 2010 04:14:25 +0000

Article

Par : Laurent Pelou

Laurent Pelou — Mon, 09 Nov 2009 21:11:36 +0000

Cela me fait penser à la session de Vincent Lextrait lors de l’USI 2008 « Du manufacturing au mindfacturing ».

En substance, Vincent disait que les bonnes idées du manufacturing (ouvrier à poste, chaîne de montage, …) ne s’appliquait tout simplement pas au développement informatique qui était avant tout un travail intellectuel (mindfacturing). A la base du manufacturing, c’est le changement d’outil qui coûtait cher, or en informatique, changer d’outils, c’est utiliser la combinaison CTRL-TAB !!!

Par ailleurs, ce qui différencie un travail physique d’un travail intellectuel, c’est d’abord les différences (de rendement) entre les personnes. Par exemple, entre le champion du monde du 100m (#10s) et ma propre performances de dimanche dernier (#16s), il y a un rapport de 1,6 arrondi à 2. Par contre, entre deux développeurs, le rapport peut être de 10, 100, 1000, 10000 voire l’infini… Je sais c’est pas politiquement correct mais cela se vérifie tous les jours.

Ce qui coûte aussi cher en informatique, c’est surtout la perte d’information entre les personnes qui travaille ensembles. On appelle cela les relations interpersonnelles et plus il y a de personnes, et plus il y a de perte d’informations.

Au final, mieux vaut ne pas organiser une équipe de développeurs par spécialité (ou outils comme dans le manufacturing) car c’est la situation la pire où les personnes ne se comprennent pas. Par exemple, un développeur IHM, un développeur « couche métier », un développeur base de données.

C’est pourtant le découpage classique qu’on trouve dans une équipe de développeur, un découpage par couche technique, un découpage « horizontal ».

En fait, pour limiter au maximum ces problèmes d’incompréhension, mieux vaut un découpage fonctionnel (ou métier) où toutes les couches techniques apparaissent.
Le projet est alors découpé par couche « verticale ».
On retombe alors sur les principes de l’agilité où c’est avant tout la valeur métier qui est mise en avant.

Bref le raisonnement ayant aboutit à l’industrialisation du manufacturing est globalement bon, mais il faut le refaire pour l’appliquer au domaine du développement informatique et ne pas chercher à transposer aveuglément les bonnes pratiques du manufacturing.

Par : JP Latour

JP Latour — Mon, 09 Nov 2009 19:08:48 +0000

Si vous défendez le fait que ce sont d’abord le respect pour les collaborateurs, l’entretien de leurs compétences et la stimulation des bonnes attitudes qui feront la différence sur la qualité je vous rejoins tout à fait.
Mais ceci étant acquis, il me semble que cela ne doit pas empêcher de mettre en place des mesures « froides » de contrôle qualité, s’inspirant du monde industriel. D’un côté La confiance se crée par les conditions de travail et le respect des hommes, d’un autre côté elle ne doit pas empêcher le contrôle sur la qualité.
Industrialiser veut dire, selon ma compréhension propre, souhaiter faire des gains d’efficacité, c’est-à-dire traquer les gaspillages, souvent encore trop manifestes aujourd’hui en développement logiciel. Dans les tests par exemple, mais aussi dans les opérations de maintenance (notamment par manque d’agilité comme dit précédemment), dans les déploiements (où franchement les marges de progrès restent considérables).
Tout cela me parait compatible avec le maintien de la satisfaction au travail. Et d’autant plus qu’il m’est arrivé d’entendre lors d’entretiens d’embauche, sous des formulations variables, « Je quitte mon emploi actuel et je viens chez vous parce que j’y perçois une volonté de s’organiser pour faire du travail de qualité ».
Grand merci pour cet échange.

Par : Erix

Erix — Mon, 09 Nov 2009 14:56:10 +0000

Je n’ai aucune résistance face à l’objet ou à SOA, bien au contraire, tout cela va dans le bon sens. Mais je ne pense pas que ni l’objet, ni SOA vont dans le sens de l’industrialisation. C’est probablement culturel, dans mon cas personnel le mot « industrialisation » n’est pas positif du tout. Exemple : j’aime la musique, mais je n’aime pas l’industrie de la musique. Je n’ai rien contre l’industrie en général, si ce n’est que je trouve qu’il y a des domaines particuliers où elle n’apporte pas que des bienfaits.

Mon idée, c’est qu’il faut plus se concentrer sur l’amélioration de la qualité que sur l’industrialisation. L’industrie n’est pas la seule pourvoyeuse de modèle pour l’amélioration de la qualité. Qui plus est, les problématiques industrielles ne sont pas nécessairement les mieux adaptées au logiciel.

Cela étant dit, je vous rejoins sur le fait que l’industrie électronique est intéressante de ce point de vue, j’avais d’ailleurs failli le mentionner dans mon post précédent !

Je suis allé lire quelques documents sur Squale. L’initiative est sympathique, mais je demande à voir des résultats sur des problèmes complexes, mis en oeuvre par des équipes compétentes. A mon humble avis, cela ne peut détecter que des divergences grossières.
Quand j’ai vu les références à McCall et à l’analyse de la complexité cyclomatique je dois avouer que j’ai pris un peu peur.

Je ne crois pas en ITIL ou des systèmes d’analyse du code ou des tonnes de documentation pour faire réellement avancer la qualité logicielle. On se cache derrière une fausse solution. En disant cela, je suis conscient de ne pas faire avancer le problème, je n’ai pas d’autre solution facile à proposer, à part former les équipes encore et toujours, améliorer la communication, etc.

Par : JP Latour

JP Latour — Mon, 09 Nov 2009 14:33:10 +0000

Certainement d’accord avec le fait que nombre de systèmes IT évoluent.
La question est de savoir s’ils n’évoluent pas trop (refactoring trop fréquents) par manque d’agilité.
Sur ce sujet il me semble que l’ »industrialisation » va devoir progresser, en mettant en oeuvre les approches et briques technologiques qui permettront d’éviter des refactoring en profondeur (dans les tréfonds du code) trop fréquents, tout en permettant de mieux gérer la non-régression ( maintien de la qualité dans le temps).
L’industrie de l’électronique (sur les principes) peut nous inspirer de ce point de vue.
L’informatique doit cesser de faire trop systématiquement dans la haute couture fait main au cas par cas. Elle a atteint la maturité au niveau des repositories de données (bien que la souplesse puisse encore être améliorée), mais il lui reste à progresser au niveau des repositories des règles et paramètres. Les évolutions en cours dans le cadre du SOA sont significatives sur ces aspects.
Je peux comprendre le scepticisme mais ne peut admettre la résistance culturelle qui s’apparenterait à ce que nous avons connu lors du passage du procédural à l’objet. Sans l’objet, nombre d’applications n’existerait tout simplement pas aujourd’hui.

Par : Erix

Erix — Mon, 09 Nov 2009 13:21:41 +0000

Nous sommes au moins d’accord sur les aspects conception et qualité.

Par contre, la construction a lieu une fois, par recopie ?

Je pense au contraire qu’un logiciel significatif (grands projets, progiciels, etc.) est un produit certes unique, mais en constante évolution. C’est là, encore une grosse différence avec l’approche industrielle. La recopie dont vous parlez (pressage de CD, mise en boite, etc.) est de la production, pas de l’informatique.

Je ne suis pas non plus certain de bien voir l’inspiration industrielle dans SOA. Réutilisation, composants, sont des mythes de l’informatique depuis bien longtemps déjà et leur mise en oeuvre nécessiterait bien plus qu’un nouveau type d’architecture, enfin selon moi.

Je crois que nous devrons faire avec des stars/gurus pendant encore un certain temps et que le temps des ouvriers producteurs de code n’est pas encore venu. C’est essentiellement une question de complexité des processus et de niveaux d’abstraction requis.

Une fois encore, c’est une question intéressante et qui mérite d’être débattue.

Je vais regarder Squale (malgré son nom peu prometteur

Par : JP Latour

JP Latour — Mon, 09 Nov 2009 12:33:30 +0000

Le développement informatique est d’abord une activité de conception, étant donné que la construction a lieu une fois. Ensuite c’est de la recopie, pas de la construction de pièces supplémentaires sur des machines réglées pour, sur base des plans établis.
Donc oui, le parallèle est plutôt à faire entre l’activité du bureau d’études plutôt qu’avec l’usine elle-même (les ateliers). C’est bien la raison pour laquelle existent aujour’d'hui les architectes à qui l’on demande rigueur de conception, formalisation non ambigüe et contrôle du respect des plans (entr’autres choses).
Ceci étant des sources d’inspiration existent du côté industriel. Les avancées vers le SOA sont là pour nous le prouver (meilleure gestion des exigences, réutilisation comme démarche plus naturelle, assemblage de composants, …).
La démarche qualité ou le lean management sont là aussi pour nous prouver que l’indusrie, à défaut de nous donner des leçons, doit nous servir d’inspiration sur certains sujets.
Qu’ils le veuillent ou non les informaticiens devront demain faire mieux en matière de qualité en particulier.
Certains le font déjà. Sur ce plan en tous cas il est urgent de réduire la dimension artistique.
L’initiative Squale est de ce point de vue à suivre de près.

Par : Erix

Erix — Sun, 08 Nov 2009 15:20:20 +0000

Bravo pour cet article !

Cela fait longtemps que je bataille pour dire que l’industrialisation du logiciel n’est pas un objectif réaliste au moins à moyen terme.
Et il n’est d’ailleurs probablement même pas souhaitable.

Pour moi, s’il fallait absolument utiliser des métaphores, je pense qu’un projet informatique serait assez proche d’une activité artistique, comme la production d’un disque par exemple.

Si la question est comment produire plus vite plus de code, je ne pense pas que l’industrie fournisse des modèles applicables pour le logiciel. Et qu’on arrête d’associer « industriel » et « qualité », un produit industriel n’est pas un produit de qualité, c’est juste un objet produit rapidement en grande quantité.

Encore bravo, d’avoir ouvert le débat, sur ce sujet rarement remis en cause.

Par : Arnaud Héritier

Arnaud Héritier — Sat, 07 Nov 2009 20:33:40 +0000

Je tiens simplement à féliciter OCTO qui a porter le discours de l’industrialisation de développements pendant très longtemps et qui sait aujourd’hui le remettre en cause. Je suis complètement d’accord avec votre analyse et c’est vrai que l’on continue à trop souvent utiliser cette métaphore (loin d’être bonne) à défaut de trouver mieux … Sur ce je n’ai plus qu’à me trouver un autre titre sur ma carte de visite. « Software Factory Manager » ça fait has-been.

Par : Pierre Pezziardi

Pierre Pezziardi — Sat, 07 Nov 2009 14:22:46 +0000

Merci de ce manifeste « Ne restons pas prisonnier des métaphores »..
@Nicolas Krzyzanowski si la métaphore nécessite une transposition c’est qu’elle est difficilement utilisable.
Cela dit, avant de jeter le bébé avec l’eau du bain, un des points saillants de la métaphore « industrie » et « lean » est pour moi très clair dès lors que l’on connait cette réalité industrielle, qui n’est plus Taylorienne (penseurs d’un côté, ouvriers de l’autre) depuis bien longtemps dans les usines lean, où l’on retrouve un concept central qui peut nous inspirer : des équipes autonomes responsables de l’amélioration continue de leur processus.