Discussion :

[ConcombreMagique]

Énormes projets de 20 personnes, merci de me faire rire de bon matin

ouais et bien apres tu peux avoir 100 personne je doute quelle ne travaille toute sur la meme partie, et la je ne parlais que des dev, il y a les architecte, les fonctionnels, etc

C'etait surtout pour répondre "la programmation spontané c'est quand on est tous seul ou sur un projet perso", et bien non, c'est aussi dans le milieu professionel.

[APL-AML]

09/02/2008, 19h46

Je pensais faire une synthèse mais je ne suis pas certain que ça vaille le coup.
Chacun a ses vérités sur ce sujet. L'informatique étant multiple, il faut accepter la diversité qui permet de s'enrichir.

C’est ce que j’avais posté en février 2008. Finalement, je n’ai mis que 13 ans pour rédiger cette synthèse. Ma spontanéité s’est un peu émoussée ! Structurée en 6 billets, ma synthèse oppose les Adeptes de la programmation spontanée à leurs Détracteurs.

À cette synthèse, j’ai ajouté un billet Adeptes VS Détracteurs.

■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■

• Avant-propos
• Adeptes VS Détracteurs
  
  1. Développeur VS Programmeur
  2. Programmation spontanée VS Programmation improvisée
  3. Logigramme VS Algorigramme
  4. Adeptes pondérés VS Détracteurs spontanés
  5. Traitements (Mode plan) VS Conditions (Mode street)
  6. Mise en page VS Commentaires
• Conclusion

Extrait :

Vous savez quoi ? Dans son premier message, Doloop faisait référence à l'auteur d'un livre paru dans les années 80, qui annonçait qu'il n'y aurait que 10 % des programmeurs en capacité de se passer de dessiner un algorithme pour faire un programme.

J’ai recensé le nombre d’intervenants dans cette discussion et identifié parmi ceux-ci les adeptes auto-déclarés ou potentiellement adeptes de la programmation spontanée… en capacité donc, de se passer de dessiner un algorithme pour faire un programme :

• Nombre d’intervenants : 153
• Nombre d’adeptes : entre 15 et 20

Étonnamment, le nombre d’adeptes est proche des 10% prévus il y a quarante ans par l’auteur Zaks Rodnay.

Les détracteurs de la démarche ont tous de bonnes raisons personnelles de critiquer le concept de programmation spontanée. Toutefois, il en est une commune à tous : celle de ne pas pratiquer la démarche et donc in fine d’en ignorer toute la réalité. Persuadés qu’ils détiennent la vérité inoculée par l’enseignement formel, chaque détracteur imagine le concept en l’assimilant à tort à la programmation improvisée des bidouilleurs.

Alors que valent toutes leurs diatribes virulentes, acerbes, ironiques ? Rien !

En lire plus…

---

Mon blog DVP titré de mon pseudo APL-AML est constitué de deux blogs logiques :

1. APL-AML
2. FORUMS

Les adeptes trouveront ma synthèse de cette discussion sur mon 2ème blog logique « FORUMS ».

Pour y accéder, ouvrir mon billet : SOMMAIRE « Synthèses de discussions »

Voici le sommaire de ma synthèse de cette discussion :

1. [Discussion] Qui pratique la programmation spontanée ?
   
   
   1. Doloop
      
      
      • Qui pratique la programmation spontanée ?
      • Qu’est ce que l'on peut apprendre lorsque l'on est obligé de tout faire !
      • La programmation spontanée se vit, mais ne s'explique pas fondamentalement, elle fait partie de nous.
      • 10% des programmeurs sont capables d'écrire un programme sans ordinogramme.
      • Programme bien pensé fonctionnement assuré. Programme mal pensé est à recommencer.
      • L'eXtreme Programming.
      
      
   2. Adeptes VS Détracteurs
      
      
      • Développeur VS Programmeur
      • Programmation spontanée VS programmation improvisée
      • Logigramme VS Algorigramme
      • Traitement (Mode plan) VS Conditions (Mode street)
      • Mise en page VS Commentaires
      
      
   3. Adeptes
      
      
      • Avant-propos
        
        • L’appropriation
        • Processus créatif
        • Citations sur la créativité
        
        
      • Adeptes
        
        • Envoyé par ErwanVDF
        • Envoyé par epeios
        • Envoyé par sequentaire
        • Envoyé par cedricgirard
        • Envoyé par Swoög
        • Envoyé par barjy
        • Envoyé par zecreator
        • Envoyé par 2Eurocents
        • Envoyés par d’autres adeptes glanés sur la discussion
      
      
   4. Détracteurs
      
      
      • Détracteurs
      • Diatribes
      
      
   5. LadyWasy
      
      
      • La méthode "Académique" ou non, on en a AB-SO-LU-MENT rien à faire !
      • C'est à la fin du bal que l'on compte les musiciens
      • Conception mentale d’un algorithme
      • Trois profils de codeurs
      • Certaines idées préconçues ont vraiment la vie dure
      • Documenter : comment, avec quels outils ?
      • Deux définitions du terme « spontané »
      • Formalisme "conventionnel" ou "personnel"
      • Incrédules et obtus !
      • Quelques règles élémentaires
      
      
   6. APL-AML
      
      
      • Programmation à main levée et Sophrologie
      • Une application « tout-de-suite »
      • Structurer l’inconnu
      • Méthode d'investigation
      • Marcher sans se tenir à son trotteur
      • La programmation mentale

---

PS : Chaque membre ne dispose que d’un seul blog DVP identifié par son pseudo. Cependant, rien n’empêche un blogueur de partitionner son blog DVP en plusieurs blogs logiques.

Bien que mon blog DVP et mon 1er blog logique aient le même titre, c’est-à-dire mon pseudo APL-AML, ils ne recouvrent pas la même réalité. Dans un premier temps, je n'avais aucune raison de les distinguer. Le concept de blogs logiques ne s’est imposé que lorsque l’ensemble des billets de mon blog DVP est devenu une entité distincte ayant la forme d’un tutoriel abouti et quasi immuable. Continuer à bloguer tout en préservant l’intégrité de cette entité, donc sans lui ajouter de billets, m’a inspiré le concept de blogs logiques.

Constitué d’une cinquantaine de billets, mon 1er blog logique APL-AML (Au Pied Levé – À Main Levée) est une monographie qui axiomatise une approche du développement 100% ascendante (bottom-up).

• Pour les adeptes de la programmation spontanée, ma monographie peut-être vue comme un tutoriel sur le développement spontané d’application.
  
  Une application de gestion, c’est plusieurs fonctionnalités. Il suffit d’une première fonctionnalité opérationnelle pour la faire exister. Une fonctionnalité n’existe pas ? Les gestionnaires s’en passent jusqu’à ce qu’elle existe. Le matin, elle n’est encore qu’à l’état de besoin en train d’infuser dans le cerveau du développeur, l’après-midi, sa programmation spontanée la fait exister et les gestionnaires l’utilisent comme si elle avait toujours existé.
  
  
• Pour les gestionnaires, leur application existe vraiment dès le premier jour. Ils-elles disposent déjà d’un embryon de menu et d’au moins une première fonctionnalité opérationnelle, généralement une saisie simplifiée. L’application n’est jamais complète bien sûr, mais cela n’a aucune importance, les gestionnaires ne le savent pas, ils-elles n’utilisent que les fonctionnalités dont ils-elles ont besoin sur le moment ; les prochaines s’implémenteront le moment venu. Ce n’est pas plus compliqué que ça. Il faut juste oser et avoir confiance en soi.
  
  
• Pour les détracteurs corsetés dans leur conformisme, c’est clairement un texte subversif. Cependant, ils pourront constater que la programmation spontanée n’a rien à voir avec la perception qu’ils en ont. Ils y retrouveront quelques grands principes évoqués dans mon billet Adeptes VS Détracteurs :
  
  
  • Appropriation,
  • Engagement,
  • Programmation mentale,
  • Hiérarchisation par traitement,
  • Nommage significatif,
  • Lisibilité et simplicité du codage,
  • Mise en page de la programmation.
  
  
• Pour les blogueurs, c’est un blog logique et un tutoriel sous forme de billets de blog.
  
  Il y a trois façons de définir un blog logique :
  
  
  • Via la Description du blog
  • Via les Catégories de l’utilisateur
  • Via un billet Sommaire
  
  Mais je m’éloigne du sujet…

APL-AML

[el_slapper]

Bonjour.

Je suis en train de lire. Remarques en vrac, au fil de la lecture.

[0] Ce n'est pas de l'informatique, c'est de la sociologie. J'adore la sociologie. C'est aussi de la psychologie, et j'aime bien aussi. Il me semble que tu as aussi bien cerné les détracteurs - qu'on rencontre dans tous les domaines. Si tu sors des clous, tu te fais flinguer. Par principe. Ils ne comprennent pas

[1] exemple en COBOL. Tu sais me parler. Par contre, je ne suis pas d'accord avec les commentaires. Les commentaires sont utiles quand bien utilisés. Quand ils disent le pourquoi de la chose (et surtout pas le comment). Si je fais un code clair du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 IF Type-Payement-TIP AND Montant-A-Payer GREATER OR EQUAL THAN 1000000
     SET Type-Payement-Cheque TO TRUE
 END IF

Je sais parfaitement ce que fait mon code (forcer le payement à chèque au lieu de TIP, même si on a le payement paramétrer à TIP). C'est du sexycodage, c'est bien, c'est bon. Mais quand tu reviens dessus des décennies après, tu te demandes, "mais pourquoi diable forcer le payement par chèque quand le montant atteint un million?????". Réponse avec le commentaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
*Les préimprimés TIP n'ont que 6 caractères avant la virgule. Mr Machin justifie, dans son mail du 14/08/1995, le forçage à payement par chèque dans ce cas rare.
 IF Type-Payement-TIP AND Montant-A-Payer GREATER OR EQUAL THAN 1000000
     SET Type-Payement-Cheque TO TRUE
 END IF

Et là, on sait pourquoi.

Je ne suis pas non plus convaincu par l'absence de PERFORM. Un PERFORM bien conçu fait gagner du temps. Par contre, il doit être parlant, et correctement agencé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
PERFORM INITIALISATION
PERFORM TRAITEMENT
PERFORM FINALISATION

n'apporte rien. Autant faire un programme direct et ne pas se faire chier avec cet entête.

Par contre,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
PERFORM INITIALISATION
PERFORM TRAITEMENT
  UNTIL CONDITION-SORTIE
PERFORM FINALISATION

apporte beaucoup : on sait soudain que le début et la fin sont fait une seule fois, par contre le milieu est itératif. Et au plus la condition de sortie sera explicite, au plus l'ensemble sera lisible par le pauvre malheureux qui doit se farcir l'analyse de 800 programmes en trois mois (moi, en 2014).

[2] Mettre en page ses programmes. là, 100% d'accord. C'est encore du sexycodage. Oui, on doit comprendre tout ce que fait le programme d'un simple coup d'œil. Ca n'élimine pas le besoin de commentaires à mon sens. Mais les commentaires doivent être un plus, pas un mal nécessaire. Un plus à long terme, qui donnent le pourquoi, et surtout pas le quoi ou le comment (si on ne devine pas le quoi ou le comment du premier coup d'œil, alors ce n'est pas sexy. donc c'est mal). Le pourquoi n'a pas à apparaitre dans le code lui-même - d'où sa présence dans le commentaire.

[3] J'aime beaucoup ta théorie sur l'imprégnation. Ca revient à Joel Spolsky qui cherchait des développeurs capables de penser à plusieurs niveaux d'abstraction simultanée. Capables de penser l'algorithme et son implémentation, mais aussi le contexte plus global (application entière, utilisation, contexte économique.....)

You need training to think of things at multiple levels of abstraction simultaneously

On retrouve ça dans ta théorie sur l'imprégnation. Il faut penser à plusieurs niveaux d'abstraction pour s'imprégner de l'ensemble. Sans celà, on est obligé de suivre les rails. d'où la réaction violente des détracteurs. Peut-être pas tous, mais beaucoup, n'ont pas cette capacité. Ca leur fait peur. Que d'autres aient cette capacité est effrayant. La violence - mais aussi la spontanéité - de leur réaction, s'expliquent par cette peur de l'inconnu. Si ils ne peuvent pas, alors personne ne doit pouvoir.

Et ça explique aussi l'enseignement : on veut faire un grand nombre de programmeurs, donc on sélectionne large, donc on prend des gens qui n'ont pas cette capacité, donc on doit les guider pas à pas tout au long du projet. J'anticipe sur tes citations de l'excellent zecreator un peu plus loin, mais quand il dit que les petites structures ne peuvent pas se permettre, c'est exactement ça. J'ai fait une remarque en Janvier comme quoi nos tests automatiques d'interface ne couvraient pas la nouvelle version de telle fonctionnalité. A la mi mars, mon chef m'a dit "c'est ta nouvelle priorité". Et je dois me demerder. Alors que nos experts sont surbookés, je dois établir un plan complet , trouver tout ce qui mérite d'être couvert, mettre en place un urbanisme global, une architecture technique, réaliser, tester, adapter en fonction des surprises trouvées, valider, et mettre en production les scripts. Seul.

Je ne vais pas me faire chier à tout mettre au propre. J'ai craché 6 ligne sur papier au début pour m'aider à réfléchir. Depuis, je code, je fais propre, et je progresse. Tout est dans ma tête. Je suis à l'image de ce que décris DoLoop. Et je dois aller vite et faire bien. Et les autres membres de l'équipe, au passé bien moins technique que le mien, doivent arriver à me lire.

J'ajoute encore qu'il m'est arrivé de passer par l'étape papier., de manière plus importante. Simplement parce que j'avais atteint les limites de ce que mon cerveau peut charger en mémoire, et soudain, une bon schéma papier devient indispensable. Une fois, j'avais une page de schéma. Un schéma avec plein de boites et plein de traits. Il le fallait. En plus, ça m'a aidé à communiquer sur ce quoi je bossais. Mais le contenu des boites était fort complexe, et je ne me suis pas fait chier à le ressortir. Il y avait une boite "calcul des adresses clients", une boite "calcul des données assurance automobile", et ça suffisait.

[4] J'adore la créativité. Rien à ajouter sur cette partie.

[5] La partie détracteurs est fort rigolote. elle colle avec ce que j'ai dit au point [0]

[6] LadyWasky amène le point important de la documentation. Pour mois, il faut le strict minimum qui permet de retrouver. J'ai fait un gros projet de refonte, ou les gens en aval m'avaient donné une spec du format qu'ils attendait, avec toutes els données nécessaires. J'ai rendu 2 docs. La première était le dessin de chaine (indispensable pour passer en prod). Le deuxième était la spec des gens en aval, complétée par le nom du composant ou la donnée était calculée. C'est tout. Si les programmes sont propres, on cherche à maintenir la taxe d'assurance automobile, on voit que c'est dans le "calcul des données assurance automobile", on regarde le programme, et on a la vérité.

Si j'avais fait une spec décrivant l'algo de calcul de la taxe d'assurances automobile, il aurait été très vite obsolète. donc faux. Le programme, lui, dit la vérité de ce qui est (ce qui doit être, c'est autre chose, mais la spec que j'aurais écrite moi aurait été obsolète encore plus vite que le code).

[7] Aaaaah, en fait tu est IFA2377, l'informaticien fonctionnaire. Ca explique quelques petits trucs. Notamment que tu as toujours travaillé en électron libre. Je n'ai jamais eu ce luxe. D'où sans doute nos dissensions sur les commentaires. J'aime ton gout du risque, on m'a, en ses lieux, beaucoup reproché le mien.

Au final, ce que tu dis sur les détracteurs me fait penser à Carlos Tinoco.

Il parle de "surdoués" Mais ce qu'il dit des surdoués eux-mêmes n'est pas important. Ce qu'il dit, en creux, sur le groupe opposé, les "typiques" est bien plus intéressant. Et je dirais que ce qu'il dit des typiques concerne bien moins que les "non-surdoués". Des non typiques, on en croise à toutes les échelles de QI. Les "typiques" tels qu'il les décrit ne font sans doute que 50 ou 70% de la population, pas les 97.7% des gens dont le QI est en dessous de 130 (définition habituelle des surdoués). Mais ils sont majoritaires. Et leur mode de fonctionnement principal, c'est la soumission au récit collectif. Ce n'est même pas qu'ils sont moins intelligents (je déteste cette distinction surdoués / non-surdoués). C'est juste qu'ils ont un mode de fonctionnement ou chacun va suivre le rôle qui lui est prédéfini. Et que la seule improvisation qu'ils permettent, chez eux comme chez les autres, c'est les manœuvres pour atteindre un rôle plus prestigieux. Tout le reste doit suivre scrupuleusement la partition écrite à l'avance.

Donc quand toi, "surdoué" ou pas, tu présentes un mode de fonctionnement qui ne leur est pas accessible, eh bien du entres dans la zone de ce qu'ils ne permettent pas. Et tout sera bon pour te faire taire. Avec violence. Parce que le simple fait que tu existes, que tu leur fasse entrevoir des choses que leur beau récit collectif ne prévoit pas, les plonge dans des abîmes d'angoisse. On ne tape jamais aussi fort que quand on a peur.

[Pyramidev]

Les commentaires sont utiles quand bien utilisés. Quand ils disent le pourquoi de la chose (et surtout pas le comment).

Je nuancerais ce point. Les commentaires doivent généralement expliquer le pourquoi, rarement le comment.

Voici une version altérée d'un commentaire que j'ai écrit dans un de mes algorithmes, à mon boulot :

Explication de l'algorithme dans le cas où il y a 3 ensembles A, B et C :

Le but est de récupérer tous les éléments des tuples (x, y, z) tels que :

• x appartient à A,
• y appartient à B,
• z appartient à C et
• x <= y <= z.

Pour cela, l'algorithme ne cherche pas directement les tuples (x, y, z). Il fait quelque chose de plus performant :

• Chercher min_A, le plus petit élément dans A.
• Chercher min_B, le plus petit élément >= min_A dans B.
• Chercher min_C, le plus petit élément >= min_B dans C.
• Si l'une des étapes précédentes échoue, retourner un résultat vide.
• Chercher max_C, le plus grand élément dans C.
• Chercher max_B, le plus grand élément <= max_C dans B.
• Chercher max_A, le plus grand élément <= max_B dans A.
• Récupérer :
  
  • les éléments de A dans [min_A, max_A],
  • les éléments de B dans [min_B, max_B] et
  • les éléments de C dans [min_C, max_C].

Le vrai algorithme fonctionne pour un nombre quelconque d'ensembles.

Le code qui suit mon commentaire travaille directement avec un nombre quelconque d'ensembles, donc est légèrement plus abstrait que le cas particulier décrit dans mon commentaire. Ici, mon commentaire a un but pédagogique : il permet au lecteur de comprendre un cas particulier avant de comprendre le cas général au lieu de s'attaquer directement à la compréhension du cas général.
Néanmoins, je suis d'accord pour dire qu'il s'agit de cas assez rares en informatique de gestion.

Au final, ce que tu dis sur les détracteurs me fait penser à Carlos Tinoco.

Donc quand toi, "surdoué" ou pas, tu présentes un mode de fonctionnement qui ne leur est pas accessible, eh bien du entres dans la zone de ce qu'ils ne permettent pas. Et tout sera bon pour te faire taire. Avec violence. Parce que le simple fait que tu existes, que tu leur fasse entrevoir des choses que leur beau récit collectif ne prévoit pas, les plonge dans des abîmes d'angoisse. On ne tape jamais aussi fort que quand on a peur.

De mon côté, quand j'avais lu le fil présent, j'avais une analyse différente du comportement des détracteurs de Doloop.

Dans la vidéo que tu cites, Carlos Tinoco parle de contradictions chez les gens normaux entre les paroles et le comportement.

Dans le fil présent, Doloop ne donne pas d'exemple de code. Donc les intervenants extrapolent. Vraisemblablement, les détracteurs ont projeté leurs propres capacités et celles de certains de leurs collègues en se disant "si moi ou tel collègue code avec la démarche de Doloop, alors le code sera mauvais, donc le code de Doloop est sûrement mauvais". En vrai, peut-être que le code de Doloop est largement plus maintenable que celui d'un développeur moyen, mais il n'y avait pas d'exemple pour pouvoir juger.

[Bousk]

Dans le fil présent, Doloop ne donne pas d'exemple de code. Donc les intervenants extrapolent. Vraisemblablement, les détracteurs ont projeté leurs propres capacités et celles de certains de leurs collègues en se disant "si moi ou tel collègue code avec la démarche de Doloop, alors le code sera mauvais, donc le code de Doloop est sûrement mauvais". En vrai, peut-être que le code de Doloop est largement plus maintenable que celui d'un développeur moyen, mais il n'y avait pas d'exemple pour pouvoir juger.

This.
Mon équipe ne fait pas de fioritures, et encore moins d'étape de conception ou autres trucs pompeux. On prend la demande du designer, puis on implémente ce qu'il faut dans l'engin pour le supporter.
Au mieux si on a un doute on va discuter un peu (où placer ça ? a-t-on déjà ceci qui aiderait ? ce machin ressemble, on peut l'améliorer ou c'est spécifique pour autre chose ?), mais 95% du temps c'est juste de l'implémentation directe. KISS puis tu itères.
À côté j'ai vu des équipes avec des designs super (trop) précis qui détaillent tout et dont les programmeurs sont incapables d'écrire un code correct et surtout facilement maintenable ou évolutif. Leur point commun c'est des personnes qui n'en sont pas conscientes et croient écrire du bon code ou gérer quelque chose de difficile (alors que la difficulté réside uniquement sur la chaise et le résultat est simplement over-complexe pour rien, parce que telle notion du langage, moteur ou projet n'est pas connu ou ignoré).
La différence c'est l'expérience de chacun. Et à défaut, je ne fais pas confiance. Mais tu remarques normalement vite qui tu peux laisser faire et qui tu dois surveiller.

[vivid]

Ce fil me fait penser a pote qui voulait faire du vélo, mais tourner autour du pot sur des choix, ici d'équipement. Donc FAIT et réajuste après le tir suivant des objectifs.

[LhommeLibre]

En ce qui me concerne, j'aimerais bien programmer de temps en temps mais je n'ai pas d'idée. Dans mon travail, ça m'arrive de produire des programmes pour hacker un logiciel mais en vrai, je programme peu. En revanche, j'aime beaucoup les mathématiques et quand j'arrive à résoudre un problème, je me dis comment je pourrais le généraliser et quel programme pourrais-je produire afin de résoudre ce problème pour n'importe quel variable ? Mon programme va-t-il fonctionner pour tout les cas ? Comme je sais ça ?

Ici il y a des problèmes de mathématiques http://www.diophante.fr/index.php

Comme ça c'est possible de faire un programme bien qui me motive personnellement. Je n'aime pas réinventer la roue.