Au Pied Levé - À Main Levée

4. Détracteurs

Noter ce billet

par

, 01/04/2022 à 09h45 (597 Affichages)

Forum -► Général Développement -► Débats sur le développement – Le Best Of

[Discussion] Qui pratique la programmation spontanée ?

■ ■ ■ SOMMAIRE ■ ■ ■

Détracteurs
Diatribes

■ Détracteurs

« L’œil ne voit que ce que l’esprit est prêt à comprendre. - Henri Bergson »

La plupart des détracteurs de la démarche (tous, peut-être même) réagissent spontanément aux messages de Doloop et de ses adeptes. J’emploie volontairement cette expression réaction spontanée pour bien montrer qu’ils réagissent en connaissance de cause, qu’ils savent. Ils ne cherchent pas à comprendre l’argumentaire de Doloop, à comprendre son ressenti. L’expression programmation spontanée leur suffit pour que leur imaginaire fasse immédiatement le parallèle avec leur pratique personnelle de l’informatique et leur vécu professionnel. Combien ont-ils réellement lu les messages de Doloop et de ses adeptes avec l’esprit ouvert, la curiosité de découvrir une autre démarche que la leur ? Penser que les adeptes ignorent ce que les détracteurs condescendants leur conseillent, c’est manifestement les considérer comme des incompétents s’épanouissant soudainement dans le monde de l’informatique, vierges de toute formation.

Les réactions spontanées des détracteurs prouvent bien que la spontanéité est liée d’une certaine manière à une conviction, à l’assurance d’un savoir. Prisonniers de leurs certitudes, les détracteurs sont persuadés de détenir la vérité, celle des dogmes éducatifs dont ils sont imprégnés. Ils ne cherchent pas à comprendre l’argumentaire des adeptes, à découvrir un territoire inconnu, inattendu, ils détournent systématiquement leurs propos en les fantasmant négativement pour mieux alimenter leurs diatribes. Mais ce faisant, ils ne prouvent rien. Certains détracteurs jugent l’expression d’un point de vue professionnel scientifique ou très technique quand Doloop s’exprimait en tant qu’informaticien de gestion. Mais la plupart confond programmation spontanée et programmation improvisée.

En se trompant de cible, l’argumentaire limité et redondant constitué de diatribes et de bons conseils des détracteurs ne présente guère d’intérêt. Comme si les adeptes qui sont de vrais professionnels, aguerris au point justement d’être capables de pratiquer la programmation spontanée, ignoraient leurs classiques. Discréditer les adeptes sans savoir ni même chercher à savoir, rassure sans doute les détracteurs quant-à leurs propres connaissances, à leur propre pratique.

Le professionnalisme des adeptes se reconnait dans leurs messages. Ils expriment leur expérience et leur ressenti avec sagesse, réflexion, sensibilité, compétence, philosophie et psychologie. Leurs messages bien construits transmettent un discours de qualité.

À l’inverse, les messages de leurs détracteurs, tenant la plupart du temps en quelques lignes d’une rédaction approximative, trahissent leur manque d’empathie et leur manque de professionnalisme. Comment croire quand on lit leurs messages non titrés, mal rédigés, persillés de fautes d’orthographe et de grammaire, qu’ils programment effectivement comme ils n’hésitent pas à le conseiller. Quand on est professionnel, on le demeure quelque soit le contexte.

Métaphore :

Mon petit-fils a 10 ans. Je lui demande :

combien font 12 fois 12 ?
144
Combien font 50 fois 50 ?
2500
Etc.

Ses réponses sont spontanées. Pourquoi ? Parce qu’il connait les réponses. Soit il les a apprises, soit il les calcule mentalement.
Faut-il alors lui reprocher de ne pas poser les opérations sur papier avant de répondre ? Non ? C’est pourtant ce que reprochent les détracteurs aux adeptes de la programmation spontanée quand ils disent :

« Il me semble logique de passer par l'étape "papier" avant de se lancer dans le développement proprement dit. »

Peut-on lui demander de ne jamais utiliser sa mémoire, ni ses capacités mentales ? Non ? C’est pourtant ce que conseillent les détracteurs aux adeptes de la programmation spontanée quand ils disent :

"Ceux qui affirment pouvoir tout coder directement sans analyse sont des menteurs prétentieux."

Quand on a acquis de l’expérience, des facultés de mémorisation et de réflexion mentale, peut-on raisonnablement ne plus y avoir recours pour adopter un comportement avec la mémoire d’un poisson rouge ? Non ? C’est pourtant ce que suggèrent les détracteurs aux adeptes de la programmation spontanée quand ils disent :

"La programmation spontanée ne devrait exister que pour les petits projets personnels."

« Un esprit qui s’est élargi après une nouvelle expérience ne peut jamais revenir à ses anciennes dimensions. - Oliver Wendell Holmes »

Je laisse les détracteurs méditer cette métaphore et cette citation.

■ Diatribes

#2 En tout cas une chose est sûre, j'espère ne jamais avoir à travailler sur le même projet que toi.

Aucun projet de grande taille ne peut être mené à bien de cette façon.

#3 Exécuter dans sa tête des lignes de code une à une ne peut pas permettre de comprendre l'ensemble du programme à moins de l'avoir fait 5 minutes avant. Si tu reviens dessus quelques mois après, je pense que tu seras perdu.
Il faut toujours programmer en pensant que d'autres personnes vont relire le code sans l'avoir conçu et donc leur laisser des informations.
Ça me parait impossible d'appliquer ça sur un gros projet ou sur du travail en équipe où chacun est chargé d'un morceau du programme.

#6 … Ceux qui font de la "programmation spontanée" et qui rament pendant des jours dans un code merdique à crever ; qui ne comprennent pas la moindre ligne du code qu'ils ont écrit le jour d'avant et dans lequel ils cherchent un bug, bien évidemment ; qui bien sûr commencent directement à taper, sans la moindre réflexion préalable et qui au final, abandonnent.

#7 Se lancer dans le code directement est une chose a ne jamais faire, mais passer tout sont temps sur l'analyse et la conception ne fait pas avancer le projet et tu te retrouves à utiliser tout ton temps à spécifier.

Il faut bien dégrossir le projet dans les grandes lignes avant de commencer le code, et ensuite faire l#1es deux en même temps.
Commencer par spécifier puis coder le squelette de l'application, puis ensuite avancer de façon itérative pour chaque sous partie du projet. Analyse, codage, test puis validation et ensuite on passe à une autre partie.

#9 La façon de travailler (je n'arrive pas à appeler ça méthode) est acceptable pour des petits "tools de rattrapage". Pour ce qui est d’un projet de taille raisonnable, je ne veux même pas imaginer ce que ça pourrait donner en dehors de quelqu'un qui travaille seul. Dans une équipe, ce gain de temps sur l'étude préalable se paiera tôt ou tard, et très cher.

#10 Quand il se passe plusieurs mois entre deux intervention, mois durant lesquels tu as travaillé sur d'autres projets, tu ne peu plus avoir le code en tête.
Tu n'as pas toujours à faire à ton propre code, ou bien peut être que d'autres personnes auront à faire à ton code.
Personne ne peut comprendre un code sans commentaires. Ajouter un commentaire, fait gagner du temps sur le reste du projet.

#11 Comment travailler en équipe si on ne se met pas d'accord sur les spécifications avant de commencer à coder ?

#12 Si toi tu peux te passer de commentaires, c'est envisageable dans un contexte personnel (tu n'embêtes que toi. Mais dans un contexte professionnel, c'est un manque de savoir-faire et de savoir-vivre.

#13 Ne pas commenter du tout, ça c'est de la folie. Tu crois pouvoir t'en sortir pour l'instant car tu es plongé à fond dans ce que tu fais, mais dès que tu laisseras un peu de côté ton application et que tu devras y revenir après... je te souhaite bien du plaisir...

#49 Dans un gros projet, chacun doit se coordonner avec les autres. Comment le faire en programmation spontanée ?

#22 Tu fais comment quand tu as un pool de 15 développeurs travaillant chacun sur un module qui doit se combiner parfaitement ? Il faut bien des spécifications ?

Il faut bien des spécifications ? Pour moi, travailler sans spécifications, ni documenter le code, c'est aussi grave que de pas développer l'application.

Va dire ça aux mecs qui bossent sur les softs de Ariane 5, à 1.000.000.000 d'euros le bug, tu fais des spécifications plutôt deux fois qu'une.

Ou alors, ceux qui bossent sur le Méteor (Ligne du métro 14 entièrement piloté par ordinateur pour ceux qui connaissent pas) ? 400 vies humaines le bug. Là tu utilise les mathématiques pour prouver que ton logiciel ne plantera pas.

#107 Tu verras que mettre ton raisonnement sur le papier avant de faire le programme t'apportera beaucoup plus de rapidité que tu ne peux l'imaginer et ce sera très apprécié par ton entourage.

#108 La programmation spontanée c'est bien, en dessous de 100 lignes de code. Au dessus tu t'embrouilles.

#117 La programmation spontanée c'est uniquement pour le plaisir personnel ou de très petits projets parce que lorsque quelque chose va évoluer ça va être un gros n'importe quoi s’il n'y a pas de spécifications ni de documentation.

#126 La programmation spontanée ça ressemble à construire une maison de façon spontanée, si tu es doué ça ressemblera à une maison mais elle ne sera jamais aussi belle ni fiable qu'une maison construite avec des plans.

#128 La programmation sans analyse préalable amène inévitablement à un mauvais logiciel.

#129 La programmation spontanée ne devrait exister que pour les petits projets personnels.
Ceux qui affirment pouvoir tout coder directement sans analyse sont des menteurs prétentieux, car il a été prouvé en sciences cognitives que l'on peut retenir 7 choses simultanément (mémoire immédiate), or il existe certains problèmes qui pour être résolus utilisent bien plus de 7 variables. Bien sûr pour les petits algorithmes que tout le monde connais c'est possible, mais dès qu'il y a un besoin pour des structures ou algorithmes non conventionnels il faut analyser avant de coder pour étudier les propriétés de ces structures et algorithmes. Dès lors pourquoi ne pas noter toutes ces analyses dans un document, et documenter le code pour qu'un autre développeur n’ait pas à refaire tout ce raisonnement ?

#145 Le problème de la programmation spontanée est que si on n'a pas les idées claires ou si on est inconstant, le résultat, même s'il fonctionne sera désastreux.

Autrement dit, ce n'est pas parce qu'on est capable de programmer sans prendre le temps de réfléchir que le résultat sera suffisamment robuste pour supporter la multitude de modifications, de réglages, etc. qui attendent impatiemment, dans le couloir, d'être implémentés.

#151 Franchement la programmation spontanée c'est bon pour un "Hello World !". Après pour les applications (même les toutes petites) on est content de retrouver la documentation !

#161 Travailler au fil de l'eau sans préparer le terrain ni même documenter, c'est du grand n'importe quoi.

Se passer de la représentation papier d'un algorithme, à la rigueur (c'est ce que je fais et c'est ça que j'appelle la programmation spontanée), pour le reste, c'est un grand n'importe quoi : c'est se lancer dans la forêt tropicale sans l'équipement ad hoc pour y faire face !

#176 C'est une aberration de dire qu'on peut comprendre toutes les astuces utilisées sur l'instant sans commentaire, sans organigramme, etc.

#180 La programmation spontanée... ça rime avec suicide programmé.

#181 La programmation spontanée, ça me rappelle ce qu'un de mes professeurs appelait la méthode boxeur ; on frappe d'abord, on réfléchit après (mais ce n'est pas obligé).

#182 Je ne peux évidemment pas conseiller à qui que ce soit de travailler de cette manière, elle n'est pas réfléchie, ne laisse aucune trace donc ne permet aucun retour d'expérience... C'est tout simplement du bricolage pour se détendre.

#184 Une analyse du problème est essentielle afin de bien cerner chaque étape du processus de développement et permettre une maintenance du programme aisée pour ceux qui suivront.
Avec la méthode spontanée on arrive vite à un code que seul le codeur peut comprendre (et encore).

#192 La programmation spontanée convient bien aux codeurs qui ont du mal à raisonner de manière abstraite s'ils n'ont pas encore touché "concrètement" à des procédés de programmation. Pour eux, l'algorithme prend limite forme en dernier.

#195 Même quand on programme spontanément, on a un algorithme (ça y est le mot est dit) en tête, qu'on s'applique à retranscrire dans un autre langage (C, C++, C#, Java, etc.).

#203 À partir du moment, où tu imagines des structures complexes, c'est que tu as fait un plan dans ta tête, et que ce n'est donc plus le "spontané" dont on a pu parler récemment dans ce sujet.

Il y a une différence entre "ne pas faire de plan du tout" et "ne pas noter le plan quelque part, car on est persuadé d'être capable de le retenir (à tort ou à raison)".
À mon avis, c'est plus une histoire de sémantique qu'autre chose ici : qu'est-ce qu'on entend exactement par "spontané".
Pour moi, il me semblait que c'était quelque chose de l'ordre de : "programmer sans avoir établi de plan, donc sans savoir où on va".

#211 Il me semble logique de passer par l'étape "papier" avant de se lancer dans le développement proprement dit. Concevoir un story-board, un cahier des charges, les diagrammes UML, la modélisation des bases, est tout aussi important car le développement en sera grandement simplifié. "Penser" pour "bien faire".

#213 Le débat concerne d'avantage des grands projets. À de petites échelles, même les pires méthodes aboutissent : "Tu peux toujours tailler ta haie avec un coupe-ongle". À de larges échelles, c'est une autre histoire...

#221 Le développeur sait d'où il vient et où il va (tout le contraire de la programmation spontanée).

#222 Programmer spontanément une vingtaine ou quelques centaines de lignes, bref : un petit truc, c'est à la portée de toute personne programmant de manière "naturelle" (J'ai envie de dire "de toute personne ayant un peu de talent", mais j'ai peur de me faire des ennemis).

En revanche, programmer "spontanément" un gros logiciel, donc sans faire le point aux moments importants du développement, sans faire de plan, sans chercher à regarder plus loin que le bout de son nez, c'est la garantie de faire une bouse infâme qui ne fonctionnera pas.
La programmation spontanée à une grande échelle (= gros logiciels), ça n'existe pas. Dans le cas contraire, après tout, je peux me tromper : citez-moi quelqu'un qui a programmé spontanément (donc tout seul) et avec succès, quelque chose d'aussi conséquent que windows Vista.

#226 En ce qui me concerne la "programmation spontanée" tient au fait de programmer sans suivre de plan préétabli.
… On peut moins faire attention à ce qu'on fait, on se rapproche donc un peu plus de la "programmation spontanée".

#245 Les idées fusent rarement pendant la phase "pissage de code".

#252 Mais même pour de petites applications, pratiquer de la programmation spontanée peut être quasiment impossible.

#263 Celui qui dit "je programme spontanément" (le concept et l'organisation sont représentés dans ma tête), c'est celui qui veut faire une cabane).

#267 Comment appliquer cette méthode quand on est seul développeur, que l'on doit effectuer de la semi-administration serveur, et faire de la hotline, former les utilisateurs finaux et que vous devez répondre à des besoins informatiques quasi quotidiens ?

#294 Pour moi, ça serait réfléchir à ce qu'on va faire, dans sa tête, peut-être en discuter avec un ou deux collègues qui bossent sur le même projet, puis se mettre à coder. Et c'est tout (rien avant, rien après).

Je l'ai déjà fait sur de petits projets, mais uniquement pour des maquettes, ou des projets dont on savait qu'ils ne seraient jamais repris (durée de vie limitée à quelques jours, par exemple).

Si de nombreuses personnes sont impliquées, ce n'est plus possible. Tout simplement parce que réfléchir et discuter ensemble (et surtout se comprendre) à plus de 50 personnes (éventuellement réparties géographiquement), sans utiliser de support physique, c'est presque impossible. Donc là, la "programmation spontanée", telle que je l'imagine, n'est plus applicable (sauf peut-être pour le petit bout de code dont je serais responsable).

#300 Je vois les applis télécom (pas toutes, mais si tu regardes un peu les standards 3GPP et autres protocoles télécom, tu te rendras compte que tout avoir dans la tête, même si on est "créatif", c'est impossible), des projets de refonte de SI dans les banques, des applis médicales, certains projets de la défense, des projets aéronautique (tu te vois coder tout seul tout le système informatique d'un Airbus ???)...

#305 Est-ce qu'on a déjà vu des ingénieurs dans l'automobile construire une voiture, en corrigeant et en testant, avant de dire : "OK, vous pouvez en faire d'autres comme celle-là", sans faire une étude structurée, des modélisations 3D, des tests en simulations,

... A-t-on déjà rencontré des ingénieurs en aéronautique, assembler des bouts de métal avant de réfléchir en projet et en commissions aux différents aspects de l'avion ? Ou encore, le viaduc de Millau a-t-il été construit au "feeling" ? Pourquoi l'informatique ne serait pas elle aussi rigoureuse ?

#306 Je n'ai rien contre les petits génies, ils sont là pour avoir des idées, mais il faut qu'ils se contentent de ça, c'est absolument incompatible avec une programmation professionnelle.

#308 Utiliser ce type de programmation lorsque tu as des clients qui paient des milliers d’€, c'est un peu suicidaire.

#311 La programmation spontanée telle qu'elle est définie au début de ce fil n'est envisageable que pour un prototype.

La programmation spontanée ne doit être employée qu'au début d'un développement. Elle permet au développeur de se poser certaines questions et de ne pas se retrancher derrière une quelconque méthode d'étude. Il faut ensuite le structurer, ne serait-ce que pour l'optimiser. Car si tout le projet est géré de la même façon, on va droit dans le mur...

#319 Pour un programme simple de quelques centaines de lignes, quel que soit le langage, le développement peut être fait en programmation spontanée, ce que je fais régulièrement, avec un attachement tout particulier à commenter mes lignes de code (et là on s'y retrouve toujours plus tard).

Cette manière de programmer intuitive demande de la rigueur dans sa manière de penser le programme et quelques années (!) de métier et de connaissance mais elle a l'avantage de ne pas trop perdre de temps à une analyse pas toujours essentielle dans de pareils cas.

#334 La programmation spontanée, c'est bien (sur le coup), c'est rapide, Il y a "souvent" des résultats "rapides" mais quand il faut reprendre ou ré intervenir ultérieurement... Bonjour !

#350 La programmation spontanée, que je considère non-rigoureuse, requiert un certain talent pour qu'elle ne génère pas du code bon à jeter dès qu'on veut le retoucher.

#352 Avec programmation spontané, bugs spontanés, surtout les bugs d'architecture !

#405 Soit on suit une méthode, et donc on est "méthodique", soit on n'en suit pas, et donc on est "spontané" : c'est du vocabulaire de base.

#427 Bon euh... Gentil ou Méchant ?... Aller gentil.

Ce n'est pas de la programmation spontanée, c'est de la bidouille. Si un jour tu es développeur dans une entreprise sans changer de discours tu as deux choix :

Tu n'y arriveras jamais car tu vas te prendre une claque dans tes études,

Tu comprendras jamais rien et tu vas foirer tous tes projets sans t'en rendre compte.

Aussi je souhaite bon courage à tout ceux qui auront à travailler avec toi.

#436 De toute façon, la programmation spontanée, c'est comme la génération spontanée : ça n'existe pas.

#441 Ça existe sûrement cette "programmation spontanée", à mon avis, c'est surtout l'expression d'une affinité avec certains problèmes bien spécifiques. Un peu comme ces gens qui ont le sens de la musique, le sens de l'orthographe ou autre : c'est juste une affinité avec une certaine réalité du monde. J'ai un peu de mal à m'exprimer là-dessus...

Enfin bref, ça existe, mais ça n'a pas vraiment de place dans l'univers rigoureux de l'informatique industrielle. Dans la recherche, peut-être...

#444 Si la technique permet à la personne qui la pratique, de gagner du temps, au contraire elle en fait perdre à l'ensemble de l'équipe du projet.

#445 C'est impossible la programmation spontanée. Personne ne peut ne pas réfléchir à son programme ni avant ni pendant. Nous ne sommes pas des médiums, nous sommes des scientifiques.

Nous n'utilisons pas des boules de cristal, nous utilisons une machine déterministe à programmer mathématiquement.

Donc, comme je le disais, la programmation spontanée est à l'informatique, ce que la génération spontanée est à la biologie: un mythe.

#450 Calculer vite n'a rien à voir avec faire un programme sans réflexion, ni à main levée. Si tu le fais vite, ne veux pas dire que tu ne fais pas de plan. Donc ce n'est pas spontané.

Einstein était très bon ; Gauss aussi ; Euler était incroyable ; Leibniz n'en parlons pas. Ils n'ont pourtant jamais fait de la science « sans y réfléchir » ou « sans esquisse ». Alors qui, ici, se permettrait de dire qu'il en est capable ? Qui serait le prétentieux qui dirait ça ?

La non-pensée existe dans les arts martiaux, mais pas dans les sciences. C'est antinomique. On a des intuitions en science et elles sont fondamentales. Mais elles ne servent que de bases et non de « tout ».

#464 Qui pratique la programmation spontanée ?

Tous ceux qui ont levé la main, baissez la ! Vous avez sans doute un certain talent, mais il pourra un jour vous faire défaut, et la chute se fera alors sans filet...

Sachez que dans la réalisation des œuvres de ce qu'on appelle un génie, intervient seulement environ 10% de son talent, tout le reste est du travail ! Et ce travail peut être notamment un travail de discipline et d'ouverture aux autres.

Il n'y a pas à se monter la tête avec de la programmation spontanée, c'est assurément quelque chose de bien trop personnel pour être bon dans ce monde de communication !

#367 Le mot algorithme vient de Al-Khwārizmī qui était un mathématicien perse (beaucoup se trompent en le disant arabe). Il est aussi à l'origine du principe de l'algèbre dont le nom vient de l'arabe al-jabr. Il a produit de très nombreux résultats en arithmétique, en algèbre, en astronomie etc. Il est né au VIIIe siècle.

#477 Pour ma part, j'ai déjà tenté la programmation spontanée mais rien de bien concluant. Pour moi si l'on veut vraiment avancer efficacement sur un projet il faut poser ses idées pour y voir plus clair.