Discussion :

[Issam_Lahlali]

Je trace, effectivement, un tableau bien noir de la situation, mais il est, malheureusement, fort proche de la vérité.

Mais tu peux me croire sur parole lorsque j'écris que nous regrettons tous cette situation

peut être il y a encore une incompréhension , peut etre j'ai du mal a exprimer mes idées

en gros le but n'est pas faire un framework de la mort, d'ailleurs oubliant cette idée de framework et analysant la situation suivante:

une boite utilise une librairie compliqué comme t'a bien precisé avec ton tableau noire , et moi j'integre cette boite , aprés je me rends compte que l'utilisation d'une fonctionnalité technique est trop complexe, automatiquement je vais ajouter un adaptateur ou facade pour la simplifier, et aprés un certain moment je me rends compte que j'ai une dizaine de classes qui simplifie l'utilisation de la librairie compliqué, et je decide aprés de créer un module a coté que j'appelle Framework technique ou j'ai ces 10 classes.

donc dans le cas ou t'a preciser ou la situation est proche du noire on a beaucoup besoin de cette demarche, et je repete encore le but est de ne pas refaire la roue mais proposer des calsses qui font abstraction a la complexité des librairies utilisés si ces librairies sont complexes a utiliser.

mais a chaque fois on me repond parceque t'a fais un mauvais choix de librairie, mais c'est un fait d'avoir en realité des librairies complexes utilisé dans les boites pour N raison, et comme t'a bien confirmer mon argument d'avant que c'est pas facile de la changer,c'est comme ca on peut rien y faire par contre on peut simplifier l'utilisation.

qu'est ce qui cloche dans cette démarche ?

[koala01]

Là, nous sommes d'accrord...

Mais il y a une marge importante entre tes dernières lignes et ce que laissent penser de ton approche les cinquante et une page de la discussion.

[Mac LAK]

qu'est ce qui cloche dans cette démarche ?

Uniquement en se limitant au post ci-dessus, et non pas aux 50 pages précédentes, il n'y a qu'un seul élément qui cloche : tu ne parles pas du coût, ni du risque de changements, ni du coût des changements eux-mêmes.
Or, il est primordial que tu en tiennes compte dans ton raisonnement si c'est un projet professionnel (donc vendu à un ou plusieurs clients).

Ton raisonnement, tel quel, n'est applicable QUE dans le contexte d'un projet "bisounours-opensource-gratuit", où tu codes plus pour te faire plaisir qu'autre chose, et sans avoir la pression d'un CP, RT ou financier derrière toi.

En d'autres termes, en entreprise, il n'est JAMAIS rentable d'investir (y compris du temps de codage, via les salaires) si l'on n'est pas CERTAINS de gagner de l'argent dessus (avec un risque d'erreur réduit bien sûr).

[Issam_Lahlali]

Là, nous sommes d'accrord...

Mais il y a une marge importante entre tes dernières lignes et ce que laissent penser de ton approche les cinquante et une page de la discussion.

mon approche depuis le départ est simplifier au maximum la couche technique pour se concentrer sur le métier mais il y avait en général deux réactions:

- on va pas réinventer la roue
- il y a des librairies très simples et on a pas besoin de simplifier.

pour la première idée c'était plutôt ma faute ou Framework sonne tout de suite comme une librairie qui va tout refaire dans le genre dotnet ou java.

pour la deuxième idée c'est vrai que si dés le départ on choisit les bonnes librairies on a pas ce pb mais j'ai répéter plusieurs fois que dans un monde réel c'est pas le cas et on est confronté a des lib très compliqués qu'il faut simplifier.

[Klaim]

pour le première idée c'était plutôt ma faute ou Framework sonne tout de suite comme une librairie qui va tout refaire dans le genre dotnet ou java.

Tu as proposé cette logique au niveau du language et pas au niveau d'un cas particulier d'entreprise, d'où les réponses effectivement.

- il y a des librairies très simples et on a pas besoin de simplifier.

pour la deuxième idée c'est vrai que si dés le départ on choisit les bonnes librairies on a ce pb mais j'ai répéter plusieurs fois que dans un monde réel c'est pas le cas et on est confronté a des lib très compliqués qu'il faut simplifier.

Tu as simplifié les réponses qui t'ont été donné qui se résument à : il y a effectivement des libraries généraliste largement suffisantes pour la plupart des cas (il y a toujours des exceptions à tout) et "simplifier" n'est pas une processus qui doit être fait de manière systématique.
Ici j'utilise "généraliste" au sens "courant dans a peu pret tous les types de développement". Dés qu'on sort de ce cadre, mieu vaut prendre une bibliothèque qui résoud un problème ou un domaine de problème et dans l'idéal réaliste avoir le choix de bibliothèque pour cela, ce qui revient a faire des choix de philosophie.

[Issam_Lahlali]

Uniquement en se limitant au post ci-dessus, et non pas aux 50 pages précédentes, il n'y a qu'un seul élément qui cloche : tu ne parles pas du coût, ni du risque de changements, ni du coût des changements eux-mêmes.
Or, il est primordial que tu en tiennes compte dans ton raisonnement si c'est un projet professionnel (donc vendu à un ou plusieurs clients).

pour ce cas de simplification ou N développeurs piétine toujours sur les mêmes complexités d'une librairie compliqué, je pense qu'on va gagner plus de temps que ce qu'ont va perdre, dans tout les cas ce code on l'écris qlq part et en plus N fois , il suffit de le déplacer et l'écrire une seule fois, en général ça ne peut être que bénéfique pour le temps de dev, mais t'a raison dans le sens ou il faut convaincre les responsables de l'utilité de la démarche et leur faire comprendre qu'on va gagner du temps après plus qu'on va perdre maintenant, chose qu'on a du mal a avaler plusieurs fois.

[Issam_Lahlali]

Tu as proposé cette logique au niveau du language et pas au niveau d'un cas particulier d'entreprise, d'où les réponses effectivement.

j'ai laisser tomber cette idée depuis une trentaine de pages c'était plus un cris de mécontentement avec la diversité de librairies existantes

et t'a raison j'avais tord un moment pour faire un framework commun vu l'historique de C++ et je l'est préciser un moment mais après je me suis focalisé sur le framework au niveau de l'entreprise.

et j'encourage tout nouveau langage a proposer une spec pour la couche technique comme fait Python et Ruby

Tu as simplifié les réponses qui t'ont été donné qui se résument à : il y a effectivement des libraries généraliste largement suffisantes pour la plupart des cas (il y a toujours des exceptions à tout) et "simplifier" n'est pas une processus qui doit être fait de manière systématique.

en réalité on a un code qui traine depuis des années, même avant STL ou Boost ou POCO , et on sait que le refactoring ne se fait pas beaucoup dans notre domaine donc finalement dans la majorité des projets on se retrouve avec des choses compliqués techniquement.

et c'est tout l'intérêt de suivre cette démarche pour simplifier ce qu'on trouve compliqué et si c'est possible convaincre pour utiliser les librairies modernes mais c'est pas une tache aisé.

[Klaim]

et c'est tout l'intérêt de suivre cette démarche pour simplifier ce qu'on trouve et si c'est possible convaincre pour utiliser les librairies modernes mais c'est pas une tache aisé.

Ok, mais ici "simplifier" ne passe pas forcément par un ajout d'une bibliothèque ou framework maison pour abstraire des concepts.
J'ai bossé sur des projets où les devs avaient de la bonne volonté mais vraiment pas le temps de se mettre a boost ou de connaitre a font la STL. Au final, on s'est bien débrouillé avec ce qu'on avait, en utilisant par exemple beaucoup de std::vector (qui est simple - et si tu trouves pas alors le probleme est pas dans la bibliothèque), std::string et std::map mais quasimment rien d'autre venant de l'exterieur. Une bibliothèque interne était aussi développée mais quasimment tout le code était spécifique au métier (ici le jeu vidéo) et à une architecture embarquée bien précise. Autrement dit:

On doit faire simple, mais pas simpliste. "Faire simple" ne veut pas dire "rendre simple par abstraction". Il ya des tas de façons de rendre les choses simple.

Même pour ce genre de choses, il y a des choix a faire. Quelqu'un l'a déjà dit, mais on en reviens toujours aux choix (quel que soit le métier non-systématique). La prise de décision ne s'améliorant qu'avec l'experience.

[Mac LAK]

pour ce cas de simplification ou N développeurs piétine toujours sur les mêmes complexités d'une librairie compliqué, je pense qu'on va gagner plus de temps que ce qu'ont va perdre, dans tout les cas ce code on l'écris qlq part et en plus N fois , il suffit de le déplacer et l'écrire une seule fois, en général ça ne peut être que bénéfique pour le temps de dev, mais t'a raison dans le sens ou il faut convaincre les responsables de l'utilité de la démarche et leur faire comprendre qu'on va gagner du temps après plus qu'on va perdre maintenant, chose qu'on a du mal a avaler plusieurs fois.

Des chiffres, des pourcentages, des retours d'expérience (notamment les "néfastes", qui ont coûté cher à la boîte) : il n'y a que ça.

Ton exemple ne sert à rien : "je pense qu'on va gagner plus de temps"... Tu ne convaincras jamais un CP ou un financier avec ça ! Il te faut un chiffrage du couplage faible, un chiffrage du couplage fort, un pourcentage de confiance dans la librairie actuelle, des mesures de performances objectives et liées au CdC du client, le chiffrage du remplacement de la librairie, etc.

Des chiffres, des chiffres et encore des chiffres : je n'ai JAMAIS réussi à convaincre un responsable quelconque avec juste de la théorie informatique. Pour eux, c'est simplement du fumeux et de la sur-qualité (et, objectivement, ils ont raison les trois quarts du temps).
La première fois, tu seras cordialement remercié, et ignoré. Ce n'est pas grave, c'est normal, t'es "jeune et c..", pour plagier la chanson.
Mais en attendant, tu as bien sûr envoyé un mail avec tes arguments à tes responsables, avec le point critique (pour lequel tu penses que la boîte va se planter) bien mis en évidence.

Et quand, effectivement, la boîte se plante, tu peux ressortir le mail et montrer que ce que tu as "prédis" s'est effectivement produit, avec un surcoût non négligeable sur le projet. La prochaine fois, t'inquiètes pas, on t'écoutera...
Mais c'est à toi d'analyser correctement les risques, et de les remonter systématiquement. Si tu remontes qu'il y a, par exemple, 10% de risques d'avoir un gros pépin, la solution "propre" ne sera pas retenue, mais au moins, tu es couvert et tu ne risqueras pas d'être viré comme bouc émissaire.
Si tu annonces 80% de risques d'un problème majeur, et que ta direction ne t'écoute pas malgré tout, idem : tu es couvert, c'est la tête de ton responsable qui sautera et non pas la tienne.

Mais, je le redis encore une fois : tout est affaire de compromis, de chiffrages, d'analyse de risques et d'analyse des coûts de chaque solution. Sans ça, tu peux dire ce que tu veux, ça n'aura aucun poids ni aucune valeur dans ta société.
Et, le pire, c'est que c'est tout à fait normal de ne pas être écouté si tu ne fais que jouer les Cassandre sans arguments chiffrés...

Et correctement mesurer / chiffrer ces risques, c'est l'expérience qui te le permettra... Notamment à force de te planter et/ou de voir les projets d'à côté se planter, d'ailleurs !

[metagoto]

et d'ailleurs il ny a qu'a voir le succès des templates dans les boites francaises, ou on veut même pas entendre, c'est pour cela lorsque je lis cette résistance je me demande si on parle bien de qui se passe en france ou ailleurs.

Dans les faits, ça se passe comment ?
Le chef de projet interdit l'utilisation de templates parce que c'est peu portable ? Cet argument pouvait avoir du poids, disons 10 ans plus tôt, mais à l'heure actuelle, c'est dommage d'en arriver là je trouve.

A moins que cela soit une question de difficulté intrinsèque ou une simple volonté de niveler les pratiques et les compétences dans une équipe de développement ?

Y a-il encore beaucoup de propriétés du c++ qui sont persona non grata ? Les exceptions peut être ?

soyant réaliste en france [...]

Cette question me turlupine depuis un moment déjà: ne confondrais-tu pas les sonorités "an" et "on" ? A moins que ce soit une gérondif-ite aiguë

[Issam_Lahlali]

On doit faire simple, mais pas simpliste. "Faire simple" ne veut pas dire "rendre simple par abstraction". Il ya des tas de façons de rendre les choses simple.

lorsque je dis simplifier je ne précise pas comment et d'ailleurs je ne peux pas préciser ça dépend du cas a simplifier donc tu simplifie comme tu veux on utilisant l'abstraction ou pas.

mais le but est de ne pas laisser un code compliqué qui se répète dans tout le code, ou a chaque fois le developpeur piétine et cherche a faire des copier/coller.

ce que j'ajoute en plus est le fait d'isoler cette couche qui simplifie a part dans un module a part que j'appelle Framework.

[Klaim]

et j'encourage tout nouveau langage a proposer une spec pour la couche technique comme fait Python et Ruby

Peut être que j'ai mal suivi, mais je ne vois toujours pas clairement comment tu définis "couche technique".

Si tu parles d'un framework type .NET (et les equivalent Python et Ruby), alors C++ propose la S(T)L de base, Boost propose des futures bibliothèques de la S(T)L, QT propose quasimment tout ce qui manque pour du développement disons d'UI classiques, et en plus de tout ça tu as des éventuelles alternatives généralement moins connues mais qui ont le mérite d'exister.
De loin, ça ressemble a un framework pas completement officiel dont les bibliothqèues non officielles sont en concurrence constante avec de futures meilleures alternatives.

On peut considérer cela comme complexe, auquel cas effectivement mieu vaut se cantoner a des languages qui te donnent la sécurité factice de ne pas avoir de choix a faire. Temporairement.

Personellement je fais ça quand je me fou de la façon dont les choses se passent dans un language. Notemment en Python et C#. Mais dans les logiciels sur lesquels je travail le C++ est tout simplement la meilleure alternative, d'abord pour le choix des bibliothèque, le choix des philosophies dans le code et (discutable selon les gens) les performances.

lorsque je dis simplifier je ne précise pas comment et d'ailleurs je ne peux pas préciser ça dépend du cas a simplifier donc tu simplifie comme tu veux on utilisant l'abstraction ou pas.

Je me basais sur tes dernières affirmations.

[Issam_Lahlali]

Et correctement mesurer / chiffrer ces risques, c'est l'expérience qui te le permettra... Notamment à force de te planter et/ou de voir les projets d'à côté se planter, d'ailleurs !

bien sur il faut un chiffrage avant de s'attaquer a n'importe quel dev et il faut évaluer le risque mais pour cela il faut des retours de la part de ceux impliqués dans le projet.

et si le developpeur ne remonte jamais le fait qu'une librairie est compliqué a utiliser et on fait avec en utilisant des copier/coller,jamais on pensera a chiffrer ni a changer la situation.

c'est pour cela je dis que les développeurs doivent avoir ce réflexe de simplifier mais pour avoir ce réflexe il faut qu'ils se dissocient de leur vision bas niveau du langage qui en général ne leur montre pas qu'il y a un probléme de complexité.

[Issam_Lahlali]

Si tu parles d'un framework type .NET (et les equivalent Python et Ruby), alors C++ propose la S(T)L de base, Boost propose des futures bibliothèques de la S(T)L, QT propose quasimment tout ce qui manque pour du développement disons d'UI classiques, et en plus de tout ça tu as des éventuelles alternatives généralement moins connues mais qui ont le mérite d'exister.

le probléme en C++ c'est qu'en a pas que STL ou Qt mais énormément de librairies et pour les autres pas autant que C++, et le but de la spec est d'avoir une spec unique pour la couche technique(base de données, xml,...) a ne pas confondre avec implémentation unique.

et comme je dis dans la majorité de projets on a pas que STL ou Qt , il y a MFC,WxWidgets,WTL et la liste est énorme.

et sincèrement ce sujet de spec ou pas c'est un sujet a Troll, puisque ça se terminera jamais vu le nombre de langages et de leurs adeptes qui font ça et d'autres langages qui ne le font pas et on peut rester des années a parler de ce sujet et ça reste un point de vue subjective vu que les 2 approches marche bien, et je ne peux te convaincre du contraire ni toi tu peux me convaincre de l'utilité de 36 000 librairies

[Mac LAK]

A moins que cela soit une question de difficulté intrinsèque ou une simple volonté de niveler les pratiques et les compétences dans une équipe de développement ?

Y a-il encore beaucoup de propriétés du c++ qui sont persona non grata ? Les exceptions peut être ?

A titre personnel, je vois deux raisons possibles :

• Les temps de recompilation et les problèmes de debug (pour les templates ou certaines formes de dépendances/déclarations).
• Les performances et la perte de déterminisme / temps réel (pour les exceptions par exemple).

Cela ne s'applique bien sûr pas partout, mais ce sont les arguments "sérieux" les plus courants que j'ai pu entendre. Comprendre par là "dignes d'être réellement écoutés parce qu'il y a une mesure quantifiable derrière".

Je n'ai volontairement pas mis les raisons fumeuses pouvant se résumer en "je n'y comprends rien alors je ne veux pas" et autres "je ne connais pas et je ne veux pas connaître".

bien sur il faut un chiffrage avant de s'attaquer a n'importe quel dev et il faut évaluer le risque mais pour cela il faut des retours de la part de ceux impliqués dans le projet.

C'est exactement pour ça que nous sommes plusieurs à te dire que tu manques d'expérience... Sinon, tu arriverais à évaluer ce risque, justement !

et si le developpeur ne remonte jamais le fait qu'une librairie est compliqué a utiliser et on fait avec en utilisant des copier/coller,jamais on pensera a chiffrer ni a changer la situation.

Analogie à deux balles, mais tout à faire pertinente pourtant : pour expliquer à un gamin que le feu brûle et fait très mal, tu fais comment ? Tu le tartines de Biafine toutes les heures en le laissant grandir en combinaison de vulcanologue, ou tu le laisses se brûler une fois ?
La deuxième solution est un peu violente, certes, mais au moins ton gamin fera réellement attention au feu la prochaine fois...

Ben figures-toi qu'en fait, un CP ou un financier n'est guère plus intelligent qu'un bambin à ce niveau : tant que tu ne les laisse pas se planter et prendre une mauvaise décision, qui leur coûtera leur prime de fin d'année, ils n'écouteront JAMAIS tes mises en garde, qu'ils qualifieront soit d'alarmistes, soit de sur-qualité.

L'expérience...

[Invité]

Dans les faits, ça se passe comment ?
Le chef de projet interdit l'utilisation de templates parce que c'est peu portable ? Cet argument pouvait avoir du poids, disons 10 ans plus tôt, mais à l'heure actuelle, c'est dommage d'en arriver là je trouve.

A moins que cela soit une question de difficulté intrinsèque ou une simple volonté de niveler les pratiques et les compétences dans une équipe de développement ?

Y a-il encore beaucoup de propriétés du c++ qui sont persona non grata ? Les exceptions peut être ?

En fait, c'est plus courant qu'on croit... Souvent ca se cache derrière des "règles de style" qui sont parfois (rarement) écrites, ou le plus souvent communiquées par le programmeur en chef.

La raison n'est pas la portabilité, mais la lisibilité du code.

L'idée générale est que le C++ (et d'autres langages) permet un grand nombre de dialectes. En réduisant son usage à un sous langage homogène (sans pour autant interdire telle ou telle construction, juste en l'utilisant moins), on augmente la lisibilité du code, et donc sa maintenabilité. On part ici du principe que ce qui est difficile ce n'est pas d'écrire le code, mais de le relire (pour le débuguer ou l'améliorer).

Sur des projets où il y a un (ou deux) développeur principal (genre le gars qui est là depuis le début et qui a toute l'architecture en tête, situation assez courante dans les PME ou sur des projets de taille moyenne) ces règles correspondent généralement au style de codage de ce programmeur. S'il adore les templates, t'en auras partout, et les hiérarchies de classe seront généralement un peu découragées, s'il n'aime pas la STL, ben, peu de STL, s'il vient du C, t'auras un C-like, et ainsi de suite.

En général, ces règles sont exprimées indirectement en entretien d'embauche. Quand on embauche un programmeur C++, il est rare qu'on ne l'interroge pas sur sa façon de coder (ce qu'il connait le mieux, ce qu'il aime écrire...), et qu'on ne lui montre pas un peu de code maison, histoire de voir sa réaction. Sur des projets de taille moyenne, c'est souvent le responsable technique/dev principal qui fera ces entretiens, donc les règles sont naturellement respectées parce qu'il embauche des gens "comme lui".

Le cas des exceptions est un peu particulier. Là, il y a souvent une politique unique, appliquée dans tout le logiciel, et qui se trouve quelque part entre deux positions
- les exceptions sont des choses "exceptionnelles",
- les exceptions sont le mécanisme de gestion d'erreur commun au programme

Mais à part ca, oui, les règles de style et de codage sont une chose assez courante en entreprise. Elle n'interdisent pas explicitement telle ou telle construction (là ca deviendrait stupide), mais elles vont très souvent orienter tout le programme vers des "constructions standard" et un style commun.

Francois

[Issam_Lahlali]

C'est exactement pour ça que nous sommes plusieurs à te dire que tu manques d'expérience... Sinon, tu arriverais à évaluer ce risque, justement !

a ma connaissance l'évaluation du risque se fait d'une manière itératif pas une seule fois au départ, et pour cela il faut forcement un retour et des indicateurs et le retour des développeurs c'est un truc important.

et lorsque je dis développeurs ceux qui ont était piqués une fois et qui comprennent qu'il faut simplifier ce qui est complexe.

la on entre pas dans le détail de ce qui passe réellement de l'éducation a l'école jusqu'à l'expérience des développeurs et toutes les implications d'un choix et du chiffrage et la gestion de risque ect... sinon on va écrire des romans et ça se terminera jamais

je parle d'un réflexe simple a acquérir et chacun l'acquiert a sa manière, bruler, bien encadré ou piqué

[Klaim]

a ma connaissance l'évaluation du risque se fait d'une manière itératif pas une seule fois au départ, et pour cela il faut forcement un retour et des indicateurs et le retour des développeurs c'est un truc important.

Le premier choix est le plus important souvent, parcequ'il donne l'inertie du projet, la marge de maneouvre si on découvre des problèmes lors des itérations suivantes.
C'est surtout ce premier choix qui nécessite de l'expérience, en fait c'est la raison pour laquelle l'expérience a une valeur importante aux yeux de tout le monde.

[metagoto]

A titre personnel, je vois deux raisons possibles :

• Les temps de recompilation et les problèmes de debug (pour les templates ou certaines formes de dépendances/déclarations).
• Les performances et la perte de déterminisme / temps réel (pour les exceptions par exemple).

Cela ne s'applique bien sûr pas partout, mais ce sont les arguments "sérieux" les plus courants que j'ai pu entendre. Comprendre par là "dignes d'être réellement écoutés parce qu'il y a une mesure quantifiable derrière".

Je n'ai volontairement pas mis les raisons fumeuses pouvant se résumer en "je n'y comprends rien alors je ne veux pas" et autres "je ne connais pas et je ne veux pas connaître".

Ok pour les exceptions, ça a du sens. Je rajouterais d'ailleurs le fait que certaines libs ou composants ne sont pas forcément très solides quant aux 3 safety guarantees (basic, strong, no-throw).

D'accord pour les temps de compilation ou les messages d'erreurs pour les templates. Mais de là à ce que se soit porté en tant que règle générale au détriment de la pertinence du code...

Ben figures-toi qu'en fait, un CP ou un financier n'est guère plus intelligent qu'un bambin à ce niveau : tant que tu ne les laisse pas se planter et prendre une mauvaise décision, qui leur coûtera leur prime de fin d'année, ils n'écouteront JAMAIS tes mises en garde, qu'ils qualifieront soit d'alarmistes, soit de sur-qualité.

Vous (c.a.d. beaucoup de monde ici) n'avez pas l'air de porter les chefs de projets dans votre coeur

L'idée générale est que le C++ (et d'autres langages) permet un grand nombre de dialectes. En réduisant son usage à un sous langage homogène (sans pour autant interdire telle ou telle construction, juste en l'utilisant moins), on augmente la lisibilité du code, et donc sa maintenabilité. On part ici du principe que ce qui est difficile ce n'est pas d'écrire le code, mais de le relire (pour le débuguer ou l'améliorer).

D'accord pour les dialectes. Néanmoins, il semblerait qu'il arrive qu'une simple utilisation proche du fameux exemple d'une classe Stack soit proscrit. Pour des raisons idéologiques, je ne vois pas autrement. La lisibilité du code c'est une chose, mais la pertinence des solutions exprimées au travers du code en est une autre. J'ai bien peur qu'au nom d'un "style commun", ce soit tout une application et sa maintenance qui soient affectées négativement. Et ça serait quand même dommage d'en arriver là

[Issam_Lahlali]

Le premier choix est le plus important souvent, parcequ'il donne l'inertie du projet, la marge de maneouvre si on découvre des problèmes lors des itérations suivantes.
C'est surtout ce premier choix qui nécessite de l'expérience, en fait c'est la raison pour laquelle l'expérience a une valeur importante aux yeux de tout le monde.

qui dit le contraire que l'expérience n'est pas importante, et quelle relation de parler d'expérience lorsque je demande que les développeurs doivent avoir le réflexe de simplifier

et d'ailleurs en parlant d'expérience j'ai travailler pendant des années avec un éditeur de logiciel en france qui a eu un succès énorme a l'intérieur de la france et surtout a l'extérieur , le code contient des millions de lignes de code et utilise énormément de technos et de librairies et des centaines developeurs sont impliqués , et justement la majorité des développeurs avait ce réflexe de simplifier et on avait notre framework technique qui facilite tout ce qui est complexe et les développeurs avaient le reflexe de soumettre des demandes de simplification a l'équipe de Framework technique et ça marche très très bien.

est ce que que je laisse a coté cette expérience très réussi et je suis les paroles philosophiques , certainement pas.

et surtout si on parle d'éditeurs les français n'arrive pas a s'exporter comme d'autres pays donc il y a un probléme dans la démarche suivi et lorsqu'on parle d'expérience il faut voir aussi ce qu'on fait sur les projets qui ont très bien marcher.

et lorsqu'on commence a compliquer la chose avec 36 000 facteurs a prendre en compte pour simplifier on simplifiera jamais, il faut rester au milieu et être flexible la ou il faut mais pas trop rigide et ne rien changer.