Discussion :

[martopioche]

Fait du bon code et tu verras de nouvelles occasions pour le réutiliser, au moins en partie. Il est très rare qu'un besoin ne se présente qu'une seule fois dans une vie.

Waw... Merci de cette présomption de la qualité du code que je produit... À moi de retourner une question basée de la même manière sur des présomptions : pour illustrer vos théories sur le fait que les projets ont été "trop gourmands ou préparés trop tard", vous n'avez rien de mieux qu'un projet d'étudiant ? Pour votre projet, quel était le cahier des charges ? Quel était le cout estimé ? Quel était le cout consommé ? Quel était le taux d'utilisation ? Quel était la satisfaction des utilisateurs ? Quel est le ROI ? Combien de participants avez-vous réussi à faire venir venir de plus à votre conf par rapport aux confs concurrentes au même moment ?

Ces questions paraissent hors de propos ? Pourtant, dans le cadre d'un projet commercial, c'est celles qui intéressent en priorité. Un projet informatique est en effet rarement dans le monde idéal du développeur. Oui le market change d'avis au dernier moment, oui ça a un cout, oui ça impact la qualité du code produit. Pour vous, "être les premiers" relève de la "masturbation" ? Avez vous des chiffres sur l'impact d'attendre ? Aussi bien en terme d'utilisateurs qu'en terme financier ? L'impact à long terme de ce point de vue ?

Tout comme "qualité" utilisé ici à tord et à travers, "Il est très rare qu'un besoin ne se présente qu'une seule fois dans une vie." est une formulation tellement évidente... Mais quel besoin ? Ce que vous développez, vous en faites systématiquement un framework ? Lorsque vous devez faire appel à ce que vous avez fait précédemment, déjà de quelle manière l'avez vous référencé ? Ensuite, vous l'intégrez comment dans vos nouveaux projets ? Sous forme d'une lib que vous mettez en commun avec l'ancien et donc avec le risque d'introduction de régression dans l'ancien code ou en mauvais copié-collé induisant une duplication du code ? Du coup, la troisième fois, vous vous référez auquel ?

Edit : question subsidiaire : dans le code que vous avez repris d'un tiers pour une nouvelle version, quel est l'évaluation du cout effectif de la reprise vs le dev from scratch de la même fonction ?

À nouveau, je ne dis pas que la qualité doit être sacrifiée sur l'autel de la rapidité, je n'ai jamais écris ça ! Mais considérer que la qualité doit primer sur la "rapidité de mise en prod'" n'est qu'un caprice de développeur (qui en soi ne doit pas être très performant niveau "qualité") complètement déconnecté des réalités de sa fonctions. Sauf peut être dans le domaine universitaire où il n'y a pas de contraintes économiques (j'en viens).

[foetus]

Ensuite, vous l'intégrez comment dans vos nouveaux projets ? Sous forme d'une lib que vous mettez en commun avec l'ancien et donc avec le risque d'introduction de régression dans l'ancien code ou en mauvais copié-collé induisant une duplication du code ? Du coup, la troisième fois, vous vous référez auquel ?

Cela peut être un stub ou un squelette d'application qui peut-être amélioré au fur et à mesure.
Même parce que le code est présent dans X applications en production, le code est testé en profondeur.

Mais considérer que la qualité doit primer sur la "rapidité de mise en prod'" n'est qu'un caprice de développeur

Tu peux avoir de la qualité mais il faut faire que du minimaliste, taillé dans le gras (par exemple limité l'héritage, viré les pointeurs, avoir le moins de décoration possible) et ne trop penser à l'avenir du code

[martopioche]

Cela peut être un stub ou un squelette d'application qui peut-être amélioré au fur et à mesure.
Même parce que le code est présent dans X applications en production, le code est testé en profondeur.

Non mais dans la pratique, vous faites comment en ayant une "vision à long terme" ? Le projet est lancé (perce qu'évidemment, tout le monde travaille sur un nouveau projet, la TMA et es évolutions, c'est pour les faibles), vous commencez à vous demander si vous n'avez pas quelque chose dans les tiroirs (ça ok) et sinon, vous faites une première architecture en créant un "squelette" ? Vous évaluez ce que dans le projet sera certainement nécessaire une prochaine fois ? Comment vous déterminez ce qui est pertinent ou non ?

Si on parle du squelette des webapps dans le cadre d'une SSII qui vend du forfait toujours sur le même applicatif et qui préfère son framework à du wordpress (ou équivalent), pourquoi pas. Dans tous les autres cas...

Quand au "test en profondeur"... Là aussi c'est une belle affirmation de forum. Si on a un "framework", oui. Les spécificités sont dans les différents projets, sauf que il n'y a alors pas de capitalisation sur les autres projets. Ou alors, ça remonte au Framework, donc risque de régressions...

Tu peux avoir de la qualité mais il faut faire que du minimaliste, taillé dans le gras (par exemple limité l'héritage, viré les pointeurs, avoir le moins de décoration possible) et ne trop penser à l'avenir du code

Mais à nouveau, un développeur devrait se focaliser sur la mise en production du code qu'il écrit actuellement plutôt que sur un hypothétique avenir. Si dans le cas extrême où le délais pour répondre à sa satisfaction est tel que ton manager arrête le projet alors que ta "qualité" n'est pas assuré, c'est une perte sur tous les tableaux : rien n'est en prod' et l'existant n'est même pas de qualité suffisante selon les exigences du développeur pour être sereinement repris.
Mais à nouveau, c'est de la présomption de non qualité si on privilégie le logiciel fonctionnel...

[Matthieu Vergne]

Waw... Merci de cette présomption de la qualité du code que je produit...

Si je comprends que tu puisses avoir cette interprétation, ce n'est ni la seule ni celle espérée. C'était une phrase générale (tu peux remplacer les "tu" par des "on"). Je ne sais pas comment tu codes et je m'en fiche, à toi de voir comment tu veux coder.

Pour votre projet, quel était le cahier des charges ? Quel était le cout estimé ? Quel était le cout consommé ? Quel était le taux d'utilisation ? Quel était la satisfaction des utilisateurs ? Quel est le ROI ? Combien de participants avez-vous réussi à faire venir venir de plus à votre conf par rapport aux confs concurrentes au même moment ?

Ces questions paraissent hors de propos ? Pourtant, dans le cadre d'un projet commercial, c'est celles qui intéressent en priorité.

Je vais sûrement me prendre des -1 mais j'assume.

Ces questions intéressent qui ? À part le cahier des charges et la satisfaction des utilisateurs, les autres questions ne sont pas du ressort du développeur. Un projet c'est pas des décideurs et des ouvriers qui suivent, c'est un ensemble de personnes travaillant avec des objectifs en communs. Les développeurs ne sont pas des pisseurs de code. Ils ne sont pas là uniquement pour répondre au besoin que d'autres ont décidé. Eux aussi ont des besoins, ainsi que des compétences à faire valoir dans le processus de décision. De la même manière, qu'on ne vienne pas me dire que le commercial est un gars super rationnel qui ne pense qu'à la maximisation du ROI. Qu'on ne vienne pas me dire que le patron ne s'intéresse qu'à la survie de son entreprise. L'entreprise est une chose, mais sans l'humain il n'y en aurait pas. Alors il est où l'humain dans tes questions ? En dehors des utilisateurs, nulle part. Les gars qui bossent ils en tirent quoi de leur boulot ? Du fric et c'est tout ? Quand tu dis que ces questions sont primordiales, tu ne trouves pas qu'on oublie quelque chose ?

Avec ce genre de raisonnement, on en arrive aux comportement publicitaires actuels : personne n'en veut mais comme c'est rentable on continue. On en arrive à des fraudes sur les tests de voitures, après tout le cahier des charges dit seulement qu'il faut passer les tests. Le chiffre passe avant, l'humain (éthique inclue) passe après. C'est précisément sur ce point que les plus grands polémiqueurs sur l'IA insistent [1][2][3] : la machine n'a pas nos valeurs, il faut donc se protéger de ses dérives. J'adore d'ailleurs les arguments de Wozniak, qui met justement le doigt dessus :

If we build these devices to take care of everything for us, eventually they'll think faster than us and they'll get rid of the slow humans to run companies more efficiently.

Mais à bien y regarder, est-ce qu'on fait mieux ? Tes questions elles visent quoi ? Elles mettent quoi au centre ? C'est quoi l'objectif principal ? Moi je vois que c'est la survie de l'entreprise le moteur, et cela passe par faire du chiffre. Satisfaire les utilisateurs ? Motiver ses employés ? Ça ce sont les moyens pour préserver l'entreprise, et non pas l'inverse. Si on peut faire du chiffre sans satisfaire les humains impliqués, on le fait. Et c'est ce genre de dérives qu'on s'effraye d'avoir au travers des IA, alors que c'est précisément ce qu'on fait nous-même et qui est à la source des scandales et autres procès qu'on voit fleurir chaque jour.

Alors tes questions, je suis d'accord qu'elles sont importantes. Mais de là à dire qu'elles sont primordiales... les entreprises, ou peu importe comment on les a appelé, existent depuis bien avant qu'on utilise des concepts de coût, ROI et consort. Il serait peut-être temps de faire preuve d'un peu de sagesse plutôt que de se "masturber" avec des tartines de jargon. Ce n'est pas le cahier des charges qui est important, c'est le besoin utilisateur. Ce n'est pas le coût estimé qui est important, c'est les ressources qu'on est collectivement près à investir (temps, argent, etc.) pour réussir le projet. Ce n'est pas le coût réel qui est important, c'est les leçons qu'on peut tirer de nos erreurs pour faire mieux la prochaine fois. Tes questions se réfèrent à des parties chiffrables de ce qui est primordial, et non à ce qui est primordial.

À nouveau, je ne dis pas que la qualité doit être sacrifiée sur l'autel de la rapidité, je n'ai jamais écris ça ! Mais considérer que la qualité doit primer sur la "rapidité de mise en prod'" n'est qu'un caprice de développeur (qui en soi ne doit pas être très performant niveau "qualité") complètement déconnecté des réalités de sa fonctions. Sauf peut être dans le domaine universitaire où il n'y a pas de contraintes économiques (j'en viens).

À cela je répondrai deux choses.

Primo, si je me fie au sondage, il semble qu'une proportion significative de développeurs sur DVP soient des développeurs capricieux (qui en soi ne doivent pas être très performants niveau "qualité") complètement déconnectés des réalités de leur fonction.

Secundo, les plus grands experts sont ceux qui disposent (i) d'une pratique volontaire (i.e. amélioration continue) et (ii) d'un bon coach (i.e. feedback productif). Je m'appuie pour cela sur des ténors dans la recherche sur l'expertise, mais si tu veux plus de détails je te conseille de jeter un œil à ma signature. La qualité, c'est une valeur de travailleur compétent et efficace.

Mais même si on débat, au fond on pense tous les deux la même chose : tout dépend du contexte, il n'y a pas de règle absolue. On a juste chacun nos priorités.

[Nebulix]

Et celà dépend aussi du but de l'application. S'il s'agit de fournir de l'adrénaline à des ados immatures ou de piloter un dispositif de réanimation ...

[ManusDei]

Ca dépend de l'appli comme dit Nebulix, et de combien le client est prêt à payer. Je préfère faire du code propre, testé en long en large et en travers et documenté, mais si j'ai juste le temps de produire une bêta... bah je privilégie la rapidité.

[Pelote2012]

Comme beaucoup l'on déjà dit : Faut que ça marche, faut que se soit fait dans les temps prévu ...et après si on peut faire mieux, faut voir le gain côté utilisation ou maintenance mais là c'est plus une question d'investissement. Je m'explique. Tu fais un code qui marche. mais faire mieux ça te demande 2 jours en plus. Soit tu les as et par geste commercial ou par idéologie perfectionniste tu le fais ou tu n'as pas mais tu fais quand même après la mise en place, pour que lors de la prochaine mise à jour, l'amélioration soit incluse. Et c'est là que ça peut être intéressant. Parce que si tu prévois 4 jours pour la mise à jour, mais qu'avec ton amélioration il t'en faut que 2...
Mais il faut être vigilant car un amélioration en appelle souvent une autre et c'est là qu'il faut pas partir en vrille.

[JeeDji]

Ce que j'ai du mal à saisir, c'est pourquoi forcément opposer vitesse et qualité ?

En quoi il est impossible d'écrire du code propre et maintenable dans des temps serrés ? Si vous remplacez le mot vitesse avec le mot bâclage, je comprendrais, mais c'est un faux problème de mon point de vue.

Il est vrai que mon propos aurait tendance à devenir plus difficile à maintenir sur des projets de très grande envergure. Mais dans ce cas, c'est surtout une question d'architecture, les implémentations peuvent toujours être propre et maintenable sans prendre des années. Et un bon architecte, avec de l'expérience, peut faire de la qualité sans trainer. Je pense que c'est essentiellement une question de philosophie de travail, si on entame un projet dans l'optique de faire de la qualité, et que l'on a l'habitude de le faire, on finira toujours par être en avance sur un projet "à l'arrache" en temps cumulé.

Et je pense également qu'il faut dissocier qualité et compléxité dans certains esprits, que j'ai eu à croiser.

En tout cas, ça marche plutôt bien pour moi

[Matthieu Vergne]

Ce que j'ai du mal à saisir, c'est pourquoi forcément opposer vitesse et qualité ?

En quoi il est impossible d'écrire du code propre et maintenable dans des temps serrés ? Si vous remplacez le mot vitesse avec le mot bâclage, je comprendrais, mais c'est un faux problème de mon point de vue.

Pour la simple raison que la manière dont tu vois la chose est une situation "au mieux" :

Il est vrai que mon propos aurait tendance à devenir plus difficile à maintenir sur des projets de très grande envergure. Mais dans ce cas, c'est surtout une question d'architecture, les implémentations peuvent toujours être propre et maintenable sans prendre des années. Et un bon architecte, avec de l'expérience, peut faire de la qualité sans trainer. Je pense que c'est essentiellement une question de philosophie de travail, si on entame un projet dans l'optique de faire de la qualité, et que l'on a l'habitude de le faire, on finira toujours par être en avance sur un projet "à l'arrache" en temps cumulé.

Maintenant, va trouver un architecte qui a une philosophie de travail qui favorise la qualité, et qui a pu forger son expérience/ses habitudes sur des projets où on l'a autorisé à favoriser la qualité.

Une fois que tu a attends ce stade, on peut effectivement se dire que oui, finalement c'est pas si sorcier, et encore tu ignores les gros projets (déjà travaillé sur un ERP ?). Le problème est d'arriver à ce stade où tu as pu te faire un expérience solide qui favorise la qualité. Et dans un monde où d'un côté on favorise la rapidité, et de l'autre on souhaite avoir un job juste pour dire d'être payé, ton architecte tu risque de le chercher longtemps.

Des gens comme ça il y en a, mais ceux-là c'est ceux qui veulent travailler correctement, et du coup c'est eux qui cherchent où ils peuvent bosser comme ils veulent. Donc c'est eux qui te trouvent (si tu les intéresse), pas l'inverse.

[Zirak]

Ces questions intéressent qui ? À part le cahier des charges et la satisfaction des utilisateurs, les autres questions ne sont pas du ressort du développeur. Un projet c'est pas des décideurs et des ouvriers qui suivent, c'est un ensemble de personnes travaillant avec des objectifs en communs. Les développeurs ne sont pas des pisseurs de code. Ils ne sont pas là uniquement pour répondre au besoin que d'autres ont décidé. Eux aussi ont des besoins, ainsi que des compétences à faire valoir dans le processus de décision. De la même manière, qu'on ne vienne pas me dire que le commercial est un gars super rationnel qui ne pense qu'à la maximisation du ROI. Qu'on ne vienne pas me dire que le patron ne s'intéresse qu'à la survie de son entreprise. L'entreprise est une chose, mais sans l'humain il n'y en aurait pas. Alors il est où l'humain dans tes questions ? En dehors des utilisateurs, nulle part. Les gars qui bossent ils en tirent quoi de leur boulot ? Du fric et c'est tout ? Quand tu dis que ces questions sont primordiales, tu ne trouves pas qu'on oublie quelque chose ?

[...]

Mais à bien y regarder, est-ce qu'on fait mieux ? Tes questions elles visent quoi ? Elles mettent quoi au centre ? C'est quoi l'objectif principal ? Moi je vois que c'est la survie de l'entreprise le moteur, et cela passe par faire du chiffre. Satisfaire les utilisateurs ? Motiver ses employés ? Ça ce sont les moyens pour préserver l'entreprise, et non pas l'inverse. Si on peut faire du chiffre sans satisfaire les humains impliqués, on le fait. Et c'est ce genre de dérives qu'on s'effraye d'avoir au travers des IA, alors que c'est précisément ce qu'on fait nous-même et qui est à la source des scandales et autres procès qu'on voit fleurir chaque jour.

Alors tes questions, je suis d'accord qu'elles sont importantes. Mais de là à dire qu'elles sont primordiales... les entreprises, ou peu importe comment on les a appelé, existent depuis bien avant qu'on utilise des concepts de coût, ROI et consort. Il serait peut-être temps de faire preuve d'un peu de sagesse plutôt que de se "masturber" avec des tartines de jargon. Ce n'est pas le cahier des charges qui est important, c'est le besoin utilisateur. Ce n'est pas le coût estimé qui est important, c'est les ressources qu'on est collectivement près à investir (temps, argent, etc.) pour réussir le projet. Ce n'est pas le coût réel qui est important, c'est les leçons qu'on peut tirer de nos erreurs pour faire mieux la prochaine fois. Tes questions se réfèrent à des parties chiffrables de ce qui est primordial, et non à ce qui est primordial.

J'ai surtout envie de dire, que cela dépend de l'entreprise où l'on travaille...

Mais sinon, ces questions intéressent ceux qui te paient et qui sont mieux considérés que toi dans la boite, et qui peuvent, le cas échéant, te faire mettre dehors.

Car prendre en compte l'humain, ce que ressent le développeur, ses besoins et ses envies, et lui laisser tout son temps pour faire un dev aux petits oignons, je n'ai pas l'impression que cela soit la norme, et que tu vis un peu dans le monde des Bisounours (ou que tu bosses dans une boite qui pratique tout cela et tant mieux pour toi).

Déjà quel pourcentage de dev à vraiment voix au chapitre sur les délais, ou est consulté pour savoir si techniquement un truc est possible ou non avant d'être vendu ou autre ? Certes on est pas des pisseurs de codes, mais c'est un peu comme ça qu'on est considéré dans la plupart des boites en France. On a beau faire le plus gros du boulot, on est les moins consultés et les moins considérés, dev aujourd'hui, c'est limite l'équivalent d'un mec qui bosse à la chaîne et qu'on peut remplacer à volonté. Ce n'est pas exactement vrai (le coût n'est pas le même, le temps d'adaptation pour le dev sera plus long, etc etc), mais c'est comme ça que la plupart des patrons / managers / et autres commerciaux nous traitent.

Si demain mon boss vient me dire, qu'il veut telle usine à gaz pour dans 3 jours, je ne pourrais pas lui dire qu'en seulement 3 jours, je n'aurais pas le temps de faire un code propre, bien testé et maintenable sur lequel je ne perdrais pas trop de temps en cas d'évolution futur. Faudra qu'au bout des 3 jours, j'ai livré le truc, quitte à faire des heures sup, et la maintenance derrière, ce n'est pas son problème...

Et encore, je suis en interne, je n'imagine même pas en SSII...

Primo, si je me fie au sondage, il semble qu'une proportion significative de développeurs sur DVP soient des développeurs capricieux (qui en soi ne doivent pas être très performants niveau "qualité") complètement déconnectés des réalités de leur fonction.

Bof, le sondage ne montre rien.

Le sondage demande, "selon nous" qu'est-ce qu'il faut privilégier, et pas "dans votre travail de tout les jours, qu'êtes-vous obligé de privilégier ?". Pour ma part, je pense également qu'il faut privilégier la qualité et je vote dans ce sens sur le sondage, mais ce n'est pas pour autant que dans mon travail, je peux le faire à chaque fois, ou autant que je le voudrais ou autres. Car j'ai des délais à tenir, et que les délais, qui ne sont pas définis par des devs, ou en leur demandant si ils sont cohérents, ne me permettent pas toujours de faire un super code avec toutes la doc qui va bien et tout le tintouin.

Mais même si on débat, au fond on pense tous les deux la même chose : tout dépend du contexte, il n'y a pas de règle absolue. On a juste chacun nos priorités.

Je dirais qu'on a les priorités que nos directions nous imposent. Si ta direction a une vision sur le long terme et veut que tu privilégies la qualité, tu pourras le faire. Si ta direction te demande toujours de faire des trucs pour avant-hier car ils sont organisés comme des branques, bah ta priorité, cela sera la vitesse. Encore une fois, je pense (je me trompe peut-être) que beaucoup des développeurs n'ont même pas le choix sur cette question en fait.

Sinon oui, on ferait tous du super code bien propre, bien factorisé, testé en long en large et en travers, et bien documenté. Quand on voit les projets informatiques de nos jours, je pense qu'on est loin d'être dans cette situation.

[el_slapper]

(.../...)Et encore, je suis en interne, je n'imagine même pas en SSII...(.../...)

Là aussi, ça dépend. Quand tu est en régie, avec un profil un peu demandé, franchement, tu as moins peur de te faire virer, et tu peux prendre des risques. Au pire, tu te retrouves en mission ailleurs. Et quand les risques commencent à payer(i.e. tu gagnes beaucoup plus de temps que tu n'en n'a perdu, moi j'avais économisé 3 jours de maintenance à chaque fin de mois en 10 jour de boulot, ce qui me parait raisonnable comme retour sur investissement, quand on fait de la fiabilisation), tu est le roi du pétrole(enfin, tant que tu n'as pas atteint la limite des 3 ans ).

En forfait, je ne sais pas. J'ai vu une TMA énorme avec des normes calibrées au milimètre, c'était magnifique, et ça leur faisait gagner beaucoup de temps. Mais ça ne semble pas être la norme, hélas.

[Logan Mauzaize]

Mais sinon, ces questions intéressent ceux qui te paient et qui sont mieux considérés que toi dans la boite, et qui peuvent, le cas échéant, te faire mettre dehors.

J'ai envie de dire que si on te traite comme de la merde ce sera peut-être pas une grosse perte non ?

Car prendre en compte l'humain, ce que ressent le développeur, ses besoins et ses envies, et lui laisser tout son temps pour faire un dev aux petits oignons, je n'ai pas l'impression que cela soit la norme, et que tu vis un peu dans le monde des Bisounours (ou que tu bosses dans une boite qui pratique tout cela et tant mieux pour toi).

Dis comme cela, oui ca fait un peu Bisounours. Et si c'est comme cela que tu le présentes, oui effectivement il y a des chances qu'on te refuse ce genre de demandes. Il faut savoir parler avec le coeur : l'argent

Déjà quel pourcentage de dev à vraiment voix au chapitre sur les délais, ou est consulté pour savoir si techniquement un truc est possible ou non avant d'être vendu ou autre ? Certes on est pas des pisseurs de codes, mais c'est un peu comme ça qu'on est considéré dans la plupart des boites en France. On a beau faire le plus gros du boulot, on est les moins consultés et les moins considérés, dev aujourd'hui, c'est limite l'équivalent d'un mec qui bosse à la chaîne et qu'on peut remplacer à volonté. Ce n'est pas exactement vrai (le coût n'est pas le même, le temps d'adaptation pour le dev sera plus long, etc etc), mais c'est comme ça que la plupart des patrons / managers / et autres commerciaux nous traitent.

Constamment. On me demande toujours mon RAF. C'est indispensable pour planifier. Sinon qui peut définir la charge de travail ? On peut éventuellement définir les délais mais il faut une adéquation avec la charge, c'est le B-A-BA de la planification.

Plus la façon dont ils "te" traitent, je pense que c'est surtout la façon dont ils veulent que tu crois être considéré. Comme je le disais, l'argent parle et tout gestionnaire voit par l'argent potentiellement gagné (en termes d'occurence des risques et leurs coûts associés). Changer une ressource a un coût et présentes des risques avec des coûts supplémentaires.

Te faire sentir en danger n'est qu'un des moyens pour essayer de diminuer le facteur du risque "tu te barres" et diminuer l'occurence d'un risque c'est diminuer son coût budgétisé.

Si demain mon boss vient me dire, qu'il veut telle usine à gaz pour dans 3 jours, je ne pourrais pas lui dire qu'en seulement 3 jours, je n'aurais pas le temps de faire un code propre, bien testé et maintenable sur lequel je ne perdrais pas trop de temps en cas d'évolution futur. Faudra qu'au bout des 3 jours, j'ai livré le truc, quitte à faire des heures sup, et la maintenance derrière, ce n'est pas son problème...

On est plus au temps de l'esclavage et notre métier nous permet aisémment de dire non. Et si le responsable souhaites que tu fasses des heures supp., qu'il te signe un accord sinon tu lui dis que tu as fini ta journée.

Et j'insiste sur ce principe. Soit tu as un mauvais responsable qui ne sait pas gérer. Soit il estime que le coût du développement en 3 jours et des charges/risques associés sont plus rentables que les X jours supplémentaires et ses charges/risques associés. Néanmoins, je vois mal comment il pourrait faire ce choix sans te consulter.
Car même avec une grande expérience en développement chaque code est unique et une application après quelques mois de maintenance change complètement de forme.
Donc j'opterai pour la première supposition et te barrer sera peut-être la meilleure chose à faire.

Autre point pour mettre un peu en abîme mes propos. Considérons que tu ne veux ni te barrer mais que ton responsable est un incompétent. Il a bien un responsable qui comme lui doit gérer des coûts et des risques. Que ton responsable direct prennent de mauvaises décisions est également un coût et un risque.
Si tu fais "traînier" les choses, alors ton responsable deviendra la priorité à gérer.

Et si par le plus grand des malheurs toute ta chaîne hierarchique est incompétente alors ca fera d'autant plus de raisons de te barrer parce que ta boîte finira tôt ou tard par couler.

Le sondage demande, "selon nous" qu'est-ce qu'il faut privilégier, et pas "dans votre travail de tout les jours, qu'êtes-vous obligé de privilégier ?". Pour ma part, je pense également qu'il faut privilégier la qualité et je vote dans ce sens sur le sondage, mais ce n'est pas pour autant que dans mon travail, je peux le faire à chaque fois, ou autant que je le voudrais ou autres. Car j'ai des délais à tenir, et que les délais, qui ne sont pas définis par des devs, ou en leur demandant si ils sont cohérents, ne me permettent pas toujours de faire un super code avec toutes la doc qui va bien et tout le tintouin.

Je vois cela comme l'opportunité d'exprimer ce qui nous semble juste et si un décideur (chef/directeur de projet ou autre) doit orienter sa stratégie, ce sondage sera une source d'information.

Sinon oui, on ferait tous du super code bien propre, bien factorisé, testé en long en large et en travers, et bien documenté. Quand on voit les projets informatiques de nos jours, je pense qu'on est loin d'être dans cette situation.

Perso, je vois surtout des projets où on ne s'est jamais mis une pression folle sur la qualité alors qu'il n'y avait aucune pression pour faire "vite".


Par ailleurs, j'aimerai bien qu'on définisse "rapide" (exécution vs écriture) et qualité (alignement, nommage, design, respect des standards, couverture du code/des exigences, etc.). Écrire rapidement un code propre (et même partiellement testé de manière unitaire) ne demande pas beaucoup d'effort : quelques bonnes pratiques, de bonne volonté et un peu d'intelligence.
En revanche, la conception ou une couverture correcte du code/des exigences demandent beaucoup plus d'investissement. Et par correct, j'entends un scénario précis avec des données et pas juste un truc qui dit accéder à telle fonctionnalité avec tel type de données. La manière d'accéder à la fonctionnalité doit être sans équivoque tout comme l'état du système (jeu de données inclus).

[Zirak]

J'ai envie de dire que si on te traite comme de la merde ce sera peut-être pas une grosse perte non ?

Certes mais la n'est pas la question, ce que je veux dire, c'est que toutes ces questions que Matthieu considère "triviales" presque, ce sont pratiquement les seules que se posent les décideurs, après que le code soit lisible, maintenable facilement, que tous les TU soient ok, ou autres, ils s'en moquent, au pire, le jour où il y aura une maintenance, si le job n'est pas fait dans les temps, il y a plus de chances que ce soit le dev qui saute, que le directeur d'usine hein.

Dis comme cela, oui ca fait un peu Bisounours. Et si c'est comme cela que tu le présentes, oui effectivement il y a des chances qu'on te refuse ce genre de demandes. Il faut savoir parler avec le coeur : l'argent

Moi à la limite, c'est encore différent, on en fait que du dev interne, donc l'argent, c'est le temps que l'on fait gagner aux autres utilisateurs et/ou les risques d'erreurs qu'on supprime en automatisant les choses, notre coût à nous, j'ai presque envie de dire que tout le monde s'en fou, mais c'est mon collègue (qui accessoirement est mon responsable, nous ne sommes que 2 dans le service), qui veut que tout aille en prod le plus vite possible pour montrer à la direction que l'on avance au niveau des projets, quitte à remodifier chaque dev X fois par la suite.

Constamment. On me demande toujours mon RAF. C'est indispensable pour planifier. Sinon qui peut définir la charge de travail ? On peut éventuellement définir les délais mais il faut une adéquation avec la charge, c'est le B-A-BA de la planification.

Ah mais je suis tout à fait d'accord. Chez nous la planification, cela s'arrête à dire (par mon chef) bon bah toi tu bosses sur tel projet, moi sur ça, sur ton truc, j'ai prévu X jours homme. Et point barre. Après j'ai mes X jours pour faire l'analyse, le dev, les tests, la doc, déployer, former les utilisateurs si besoin, etc etc. Les seuls changements pouvant intervenir dans la planification, (en dehors des diverses interruptions car oui, on fait aussi du support utilisateur, de la maintenance matérielle, gestion de l'ERP et de sa base de données, etc), c'est que le directeur, lors de son point avec mon responsable, dise, "bah vous faites passez ce projet avant celui la", c'est tout.

Plus la façon dont ils "te" traitent, je pense que c'est surtout la façon dont ils veulent que tu crois être considéré. Comme je le disais, l'argent parle et tout gestionnaire voit par l'argent potentiellement gagné (en termes d'occurence des risques et leurs coûts associés). Changer une ressource a un coût et présentes des risques avec des coûts supplémentaires.

Te faire sentir en danger n'est qu'un des moyens pour essayer de diminuer le facteur du risque "tu te barres" et diminuer l'occurence d'un risque c'est diminuer son coût budgétisé.

Je ne me sens pas en danger, d'ailleurs mon chef n'a pas vraiment de moyen de pression sur moi, je lui ai déjà dit que si il n'était pas content de mon travail, il pouvait me mettre dehors, je suis toujours la, donc c'est que je fais le taf, même si personne n'est irremplaçable, je suis dans la boite depuis presque 10 ans, j'ai bossé dans différents services, en dehors de ce qui concerne la direction, je connais pratiquement tout de A à Z, que cela soit les produits, les processus, etc. Ils ont plus à perdre que moi en me mettant dehors. Cela dit, ce n'est pas pour cela que l'on me demande mon avis ou pas.

On est plus au temps de l'esclavage et notre métier nous permet aisémment de dire non.

Je suis également d'accord, en théorie. Maintenant, tu es au boulot, il y a un lien hiérarchique, on est quand même un peu la pour faire ce que l'on nous dit, pas que ce que l'on a envie, et de la façon dont on a envie. On ne peut pas changer de boite tous les 15 jours non plus.

Et si le responsable souhaites que tu fasses des heures supp., qu'il te signe un accord sinon tu lui dis que tu as fini ta journée.

Je ne fais jamais d'heures supp non rémunérées (du coup je ne fais jamais d'heures supp, et du coup je ne suis pas augmenté ), c'était pour l'exemple. Encore une fois, étant dans une PME avec un très petit service ne faisant pas que du dev, mon cas est un peu particuliers, je parlais de façon général, je ne suis pas forcément soumis à tout ce dont je parlais.

Et si par le plus grand des malheurs toute ta chaîne hierarchique est incompétente alors ca fera d'autant plus de raisons de te barrer parce que ta boîte finira tôt ou tard par couler.

Ou pas, en fait on va de mieux en mieux, et dans le pire des cas, y'a la maison mère qui renfloue derrière, économiser de l'argent sur le service dev, ils s'en foutent, oui ils éviteront de devoir investir plus (genre on a demandé un 3ème mec, même en alternance, c'est non), après si je dois perdre X heures lorsqu'il faut remettre à jour des devs, à part moi que cela fait chier, personne ne s'en aperçoit (ou ne s'en préoccupe). Je te dis, mon responsable, qui est lui-même concerné, puisqu'il développe et fait de la maintenance aussi, préfère sortir X dev, pour limite justifier notre présence, (ce qui est tout à fait logique hein, si on ne sort pas un dev tous les 15jours / mois c'est forcément qu'on est en train de glander, des projets plus gros que d'autres, cela n'existe pas ), que de mettre quelques jours de plus à sortir un truc mieux foutu qu'on en retouchera pas avant un bon moment.

Si on avait pas beaucoup de taf, au pire, je pourrais comprendre, mettre du temps à faire de la maintenance, cela nous occuperait, mais bon, on est plutôt dans le cas contraire, avec des demandes des différents services suffisamment nombreuses pour tenir un bon moment (sans parler du wi-fi qui va arriver, et donc où l'on va devoir migrer plusieurs dev en version web, notamment au niveau de la gestion des stocks).


Enfin bref, encore une fois je parlais de façon générale, (dans mon cas perso, je sais à quoi m'attendre et ce que je peux ou pas, faire en conséquence), ces histoires de délais revenant très régulièrement sur le forum, cela ne doit pas être si anecdotique que ça, et comme je le disais au début de mon intervention, c'est différent dans chaque entreprise.

Ce qui m'a surtout fait réagir au niveau de l'intervention de Matthieu, c'est comme je le disais plus, le fait qu'ils considèrent ces questions comme peu importante alors qu'au contraire ce sont pratiquement les seules que se posent les décideurs qui, dans la majorité des cas, raisonnent tous à court terme.

[Matthieu Vergne]

Moi à la limite, c'est encore différent

mon chef n'a pas vraiment de moyen de pression sur moi

c'était pour l'exemple. [...] mon cas est un peu particuliers, je parlais de façon général, je ne suis pas forcément soumis à tout ce dont je parlais.

encore une fois je parlais de façon générale,

J'ai pas relu mes anciens posts (c'est que ça date cette discussion) mais en général, ce que je dis je le fais. Ça me semble un peu facile de dire la même chose que ce que tout le monde pense et de croire que si c'est différent pour soi c'est parce qu'on est un cas particulier. Ce n'est pas pour autant qu'il faut faire de son cas une référence, on est d'accord, mais en attendant la croyance populaire est que mieux vaut faire ce qu'on nous demande et ne surtout pas oser contredire la direction, ce que moi je trouve être dépassé.

[Zirak]

J'ai pas relu mes anciens posts (c'est que ça date cette discussion) mais en général, ce que je dis je le fais.

Moi aussi je fais ce que je dis, mais je ne vois pas le rapport ? Je dis que justement, on n'a pas forcément le choix entre vitesse ou qualité (quand on ne peut avoir les deux), ce sont tes managers qui choisissent, après oui, tu peux dire non, les contredire et leur prouver qu'on peut s'en sortir pour moins cher (ou gagner plus) en pensant à long terme et peut-être qu'ils t'écouteront et changeront de façon de faire, ou peut-être que tu te feras lourder pour insubordination (et oui ce n'est pas forcément un mal de quitter ce genre de boite, mais tout le monde ne peut pas se permettre de perdre son boulot quand ça lui chante).

Ça me semble un peu facile de dire la même chose que ce que tout le monde pense et de croire que si c'est différent pour soi c'est parce qu'on est un cas particulier.

Ah mais ce n'est pas forcément complètement différent, dans ce que disait Logan, il y a effectivement des choses qui ne s'applique pas à moi (typiquement prouver à mon responsable que c'est plus bénéfique pour l'entreprise de penser à long terme que de faire à la va vite, cela a déjà était fait, et il le sait, etc etc), encore une fois, oui ej suis d'accord qu'on peut dire non, mais ce n'est pas pour autant que l'on sera écouter ou que notre "non" sera pris en compte. Les "il suffit de" c'est facile aussi. Mais à côté de cela, j'ai quand même des choses qui s'appliquent, comme le fait que la vitesse passe avant la qualité (même si on ne livre pas des bouses infâmes qui ne fonctionne pas non plus, mais on pourrait faire "mieux" et plus "propre").

Ce n'est pas pour autant qu'il faut faire de son cas une référence, on est d'accord, mais en attendant la croyance populaire est que mieux vaut faire ce qu'on nous demande et ne surtout pas oser contredire la direction, ce que moi je trouve être dépassé.

Et ben c'est bien, et encore une fois "cela dépend des entreprises", si ta direction ou ton manager est ok pour écouter tes arguments et les prendre en compte tant mieux, mais il y a des boites ou si tu contredis la direction, c'est la porte directe, et donc dire "ne surtout pas oser contredire la direction, c'est dépassé, impose ton style Jean-Michel !", comme si tout le monde pouvait se le permettre, je trouve cela dangereux.

Je ne dis pas qu'il ne faut jamais l'ouvrir et toujours se laisser faire, d'ailleurs mon propos initial n'était même pas là, et toute cette discussion est limite hors-sujet. On s'en fou totalement de savoir si je suis un cas particuliers ou non, ou de dire qu'on a le droit de l'ouvrir de temps en temps car on est pas des esclaves, si ta boite bosse d'une certaines façons, soit tu fais comme elle te dit, soit tu ne le fais pas, et la c'est 50/50, soit ça passe et tant mieux pour toi, soit tu vas effectivement voir ailleurs. Mais au final, le cas où tu révolutionnes tout, reste minime, et c'était juste cela mon propos de départ : "Globalement" nous n'avons pas forcément le choix entre "vitesse" et "qualité". C'est tout. Après cela n'enlève rien au fait que si effectivement, on n'est pas content de ne pas avoir ce choix, ou de la façon dont travail la société, qu'on puisse aller voir ailleurs, chacun est libre et c'est un autre débat.


En tout cas, dans un système où chaque tâche est de plus en plus cloisonnée et où c'est une personne différente qui fait chaque truc (sur les gros projets), cela me fait rigoler de dire que nous ne sommes pas des pisseurs de code, quand tu code un truc par rapport aux specs faites par un autre gars, tu es quoi au juste ? Un analyste ? Bah non, tu pisses du code.

Sur le fond je suis d'accord avec toi, un projet devrait effectivement être un truc de groupe, où tout le monde se concerte et se sent concerné, et pas un truc avec une hiérarchie / un développement en cascade, où le dev est presque le dernier maillon, et que quand cela arrive à lui, le besoin a déjà été analysé et vendu sans même qu'il ne sache de quoi il s'agit.