Discussion :

[SlashEne]

Bonjour,

Je suis actuellement un stagière dans une petite boite d'editeur logiciel et malgrès ma jeune expérience dans le domaine professionnel, j'ai toujours été poussé a écrire un code bien conçu et propre (application de design pattern et séparation des couches).
Poussé à le faire par des profs, par des livres, par des forums, par des site comme joel on software.

Après avoir developper pendant 3 ans comme un porc (code très sale) je m'applique à faire du bon code depuis maintenant 2 ans et je suis persuadé que cela me rend les idées plus clair, me simplifie tout ce qui peut paraitre compliqué, me fait aimer encore plus le developpement, et me permet d'être plus 4 à 5 fois plus rapide qu'avant.

Cependant voila que depuis que je commence ma vie professionnelle je tombe sans arret sur du code pourri.
Il n'est pas rare que je dois reprendre une partie d'un code d'une application (que je fini par reécrire entierement) qui a 1 seul classe avec 3000 lignes de code a l'interieur.
Il n'est pas rare n'ont plus que je doive reprendre du code HTML pourri ne respectant aucune norme (pas de guillement pour les attribut, balise en majuscule etc...).
Il n'est pas rare que je tombe sur des base de donnée d'une application avec 400 table et 300 procédure stocké écrite à la main avec des nom du genre "Table1", "Table2".

Je me demande vraiment pourquoi des développeurs qui sont par définition des pro (dans le sens qu'ils vive du developpement), puisse sortir un code aussi pourri.

J'aimerai savoir si il est vraiment courant de voir ca ?
Est ce que vous pensez que c'est vraiment dangereux pour une entreprise ?
Est ce que si dorénavant je trouve un stage (ou un emploi) dans une tel entreprise avec de tel développeurs il faudrait mieu que j'aille voir ailleurs ?

[eclesia]

Je me demande vraiment pourquoi des développeurs qui sont par définition des pro (dans le sens qu'ils vive du developpement), puisse sortir un code aussi pourri.

J'aimerai savoir si il est vraiment courant de voir ca ?
Est ce que vous pensez que c'est vraiment dangereux pour une entreprise ?
Est ce que si dorénavant je trouve un stage (ou un emploi) dans une tel entreprise avec de tel développeurs il faudrait mieu que j'aille voir ailleurs ?

J'ai rencontré ca en stage, une application VB (un plugin pour une application cartographique). Bien sur c'est un module payant fait par une boite relativement connu dans le domaine, et qui est toujours vendus au jour d'aujourd'hui ...

C'est pour dire que Oui c'est courant, et le coté obligation de resultat des sociétés n'arrange pas les choses.

C'est aussi une facon d'assurer la vente des noouvelles versions et d'assurer que le client ai besoin de la boite

[TheCaribouX]

C'est pour dire que Oui c'est courant, et le coté obligation de resultat des sociétés n'arrange pas les choses.

Je maintiens aussi. J'ai également commencé un stage; alors au début les intentions de mon superviseur étaient louables, on va appliquer les design pattern, rendre le code le plus réutilisable possible... et au final 2 semaines apres, 'est "le marketing aimerait un prototype rapide".... donc un programme fait "à la va vite" .. alors j'me bats pour le structurer le mieux possible, et le faire le plus vite possible..est-ce compatible...

[_vince_]

Je me demande vraiment pourquoi des développeurs qui sont par définition des pro (dans le sens qu'ils vive du developpement), puisse sortir un code aussi pourri.

Bienvenue dans le monde reel.

Les developpeurs doivent ecrirent un logiciel qui repondent aux besoins des utilisateurs/clients et le plus vite possible. C'est deja un defi en soi.

On ne demande pas aux developpeurs d'ecrire un code de qualite. Ca prend plus de temps et le client ne le voit pas puisque l'utilisateur ne voit pas le code. Pourquoi une societe devrait livrer un code de qualite si ca coute plus cher et que ca ne rapporte rien ?

Il y a plusieurs types de developpeurs. Il y a les debutants qui apprennent le langage et la P.O.O en meme temps qu'ils codent. Et il y a les developpeurs plus aguerris qui codent mieux que les debutants. Tu dis toi meme qu'il t'a fallu trois ans pour ameliorer ton code...
Et aussi, il y a les passionnes qui veulent faire un code de qualite et ceux qui font ca pour en vivre (comme tu dis) et qui baclent leur travail. A mon avis, ces derniers constituent la majorite. Je ne pense pas que ce soit specifique aux developpeurs. Et ensuite, il y a des projets ou il n'y a apparemment pas d'architecte logiciel, personne pour inspecter le code des debutants...

Ensuite une fois que le code passe en phase de maintenance, les developpeurs corrigent ou inserent des palliatifs qui rendent le code encore plus moche et incomprehensible. Au fur et a mesure des developpeurs differents, le code devient impossible a maintenir. Tu as envie de tout jeter et de tout recommencer a zero...

Je parle d'apres ma petite experience en integration/validation logicielle ou j'ai fait la recette de plusieurs logiciels. Et effectivement, j'ai moi aussi ete surpris par la non-qualite de certaines parties de code.

Le seul danger est d'exploser les budgets de maintenance s'il y a beaucoup trop de bugs.

Je dirais aussi que dans les ecoles, on apprend un langage mais on ne nous apprend pas a coder proprement. C'est pour ca que les debutants ne sont pas au courant des bonnes pratiques. Et a mon avis, il faut plusieurs annees avant de maitriser un langage objet, et si on se documente et on si on se remet en cause souvent. Ceci explique peut etre cela...

[SlashEne]

Les developpeurs doivent ecrirent un logiciel qui repondent aux besoins des utilisateurs/clients et le plus vite possible. C'est deja un defi en soi.

On ne demande pas aux developpeurs d'ecrire un code de qualite. Ca prend plus de temps et le client ne le voit pas puisque l'utilisateur ne voit pas le code. Pourquoi une societe devrait livrer un code de qualite si ca coute plus cher et que ca ne rapporte rien ?

Je ne suis pas totalement d'accord sur l'utilité d'avoir un code propre essentiellement pour la maintenance. Si je me remettais a programmer comme je le faisais avant même sans parler de maintenance je suis persuadé que je serais 4 à 5 fois moins productif (j'espere pouvoir dire 10 fois moins dans quelques année (reference à Steve McConnel)).

Mais il est vrai qu'une personne non formé pendant ses études ou lors de projets personnelles à produire du code propre perdrait un temps fou à le faire lors de projet professionnel. M'enfin le developpement c'est le choix d'une formation permanente et un chef de projet qui néglige la formation d'une équipe de développement me semble plutôt dangereux non ?

[_vince_]

Je ne suis pas totalement d'accord sur l'utilité d'avoir un code propre essentiellement pour la maintenance.

Le code est écrit une fois mais maintenu pendant des années. En général, la phase de maintenance est plus longue que la phase de developpement. D'ou l'interet d'avoir un code propre des le début.

Steve McConnel

On a les memes references Malheureusement, tout le monde ne connait pas les bonnes pratiques.

Mais il est vrai qu'une personne non formé pendant ses études ou lors de projets personnelles à produire du code propre perdrait un temps fou à le faire lors de projet professionnel. M'enfin le developpement c'est le choix d'une formation permanente et un chef de projet qui néglige la formation d'une équipe de développement me semble plutôt dangereux non ?

Je ne pense pas que ca prenne beaucoup plus de temps de coder proprement. A mon avis, c'est inné. Il y a ceux qui sont fait pour coder proprement, et les autres qui baclent. Les perfectionnistes se font rares...

Je vais prendre un example qui peut paraitre un détail insignifiant mais qui pour moi est révélateur. Par exemple, quand tu vois un entier, qui physiquement ne peut etre que positif, stocké dans un entier signé, tu te demandes pourquoi le codeur ne la pas stocké dans un entier non signé. La raison est que ca va plus vite d'écrire "int" que "unsigned int". Ensuite, celui qui passe derriere se demande pourquoi c'est baclé.

La plupart des métiers necessitent une formation permanente. Je ne suis pas chef de projet. Mais a mon avis, vérifier la qualité du code n'est malheureusement pas la priorité du chef de projet. J'espere que des chefs de projet pourront me contredirent.

[SlashEne]

La plupart des métiers necessitent une formation permanente. Je ne suis pas chef de projet. Mais a mon avis, vérifier la qualité du code n'est malheureusement pas la priorité du chef de projet. J'espere que des chefs de projet pourront me contredirent.

Toutes mes expériences professionnelles actuelles (dans le cadre de stage), je n'ai en effet pas trouvé 1 seul chef de projet demander un code propre.
Même à plus bas niveau, mon maître de stage code comme ma grand mère .
Dans la même mesure je n'ai évidemment pas trouvé 1 seul chef de projet sachant ce que signifie "extreme programming" ou "methode agiles"...

Je suis tombé sur un article de Joel Spolsky
Cette article montre 12 étapes a avoir pour faire un meilleur code.

Un score de 12 est parfait. 11 est tolérable. Mais avec 10 ou moins, vous avez de sérieux problèmes. Le fait est que la plupart des firmes qui font des logiciels ont un score de 2 ou 3. Et ils ont sérieusement besoin d'aide, parce que des sociétés telles que Microsoft tournent à 12 en permanence.

Apparemment cela signifie bien que beaucoups d'entreprise font des logiciels crado.
(j'admet que je trouve que ce test porte plutot sur la gestion general du projet du point de vue du developpeur, plutot que sur la qualité d'un code).
Meme moi avec toute la volonté que j'ai de faire un code propre, et si j'avais le pouvoir de diriger un projet de developpement suivant les bonnes pratiques agile et de qualité de code je n'arriverai pas à faire plus de 3 ou 4 a ce test. Comment un chef de projet ne connaissant pas ce que c'est les méthodes agiles peut même ésperer arriver a 2 ???

Cependant les sociétés ou je suis et ai été, fonctionnent actuellement bien.
Bien sur je pense qu'il y a un énorme écart de compétence entre les chef de projet et les programmeur de chez microsoft et ceux que j'ai vu jusqu'a maintenant.

Je ne peux cependant pas croire 1 seule seconde que les methodes agiles, et les bonnes pratiques soit du pipo.
Je ressens les faiblesses dans les entreprises ou j'ai été lorsque l'on doit mettre à la poubelle un code illisible, ou que l'on a l'habitude de depasser les previsions.
J'ai deja entendu mon maître de stage me dire de faire un diagramme de grant pour mes previsions sur le temps que je passerais sur le projet qu'il m'a confié, et puis m'avouer en toute franchise "les prévisions et estimations ne sont jamais respécté".
Pourquoi me demander de les faire si elles ne sont pas réspecter ???
Pourtant les méthodes agiles sont consciente de cela et proposent des solutions non ?
Je suis même persuadé que le vrai développeur pro (le 10x), pourrait faire une estimation fiable pour un projet de 6 mois.homme (voir sur 1 an.homme) juste parce qu'il connait les bonnes pratiques de conceptions. (ok c'est un petit projet mais même sur un si petit projet, j'ai vu des estimations dérapées du simple au double).

Les programmeurs et chef de projet auquels j'ai eu à faire ont pourtant de l'expérience alors pourquoi continuer à faire sale ??
J'en suis revenu à lire
Analogie de la construction d'un fort pour les enfants de Steve McConnel
et j'ai trouvé pourquoi des developpeurs experimentés continue à écrire sale :

If people like the software that the team produced, and the software is successful, then that reduces the incentive to try to do better next time

Tout est bien qui fini bien !

[Franck SORIANO]

C'est un vaste débat...

J'aimerai savoir si il est vraiment courant de voir ca ?

Je dirais très très courant. Même chez les plus motivés pour faire du code de qualité. On commence par essayer de faire du code propre. Et puis quand la deadline approche, ben tout ce qui compte c'est que ça marche avant la deadline...

Est ce que vous pensez que c'est vraiment dangereux pour une entreprise ?

Dangereux : Oui et non. Ca explose les coûts de maintenance. Le problème c'est que l'entreprise (disont le management) n'a généralement pas consience du temps perdu à cause d'un mauvais code.

Est ce que si dorénavant je trouve un stage (ou un emploi) dans une tel entreprise avec de tel développeurs il faudrait mieu que j'aille voir ailleurs ?

C'est à toi de voir. Mais si chaque fois tu vas voir ailleurs, ben tu risques d'avoir du mal à trouver quoi que ce soit. Sans compter que les boîtes qui cherchent à coder très proprement risques aussi d'être très exigentes au moment du recrutement. Elles risquent de ne pas vouloir prendre un débutant sans expériences...

Je me demande vraiment pourquoi des développeurs qui sont par définition des pro (dans le sens qu'ils vive du developpement), puisse sortir un code aussi pourri.

Comme tu le dis toi-même, un pro c'est quelqu'un qui est payé pour faire ce qu'il fait. Ca ne veut pas dire qu'il est compétant et consiencieux...

Maintenant le problème est beaucoup plus complexe que ça. Je t'invite à réfléchir à la question suivantes : Qu'est-ce qu'on bon code ?
- Très souvent, dès qu'on regarde le code de quelqu'un d'autre, on trouve que c'est pourri, juste parce que ce n'est pas fait tel qu'on l'aurrait fait sois-même. Souvent, c'est même qu'une question mode.
- Est-ce que respecter une méthode de développement ou un modèle à la lettre garanti-t-il de faire du bon code ? Chaque méthodes, chaque modèle a ses avantages et inconvénients. Elles sont définies sous formes théorique, par rapport à des cas d'écoles. Mais dans la vrai vie, on ne se trouve pas dans un cas d'école. Il faut adapter, choisir le meilleur de chaque modèle pour définir SON architecture applicative...
- Les méthodes ou modèles choisis font-elle l'unanimité. Seront-elles toujours bien perçues dans quelques années ?
Il y a quelques décénies, on ne parlait que du cycle en V. Aujourd'hui on ne fait que le critiquer.
On a parlé des méthodes RAD. On les critiques tout autant.
Tu parles de "L'extreme programming" combient de chef de projet (parfaitement compétent et expérimenté) ne considèrent pas XP comme une méthode sérieuse...

Et si on se place du côté de la qualité logiciel, c'est encore pire. Il existe bon nombre de critères de qualité qui généralement sont contradictoires...

Bref, tout ça pour dire que n'importe quel code peut paraitre être du bon code un jour, et complètement pourri le lendemain.

Le problème de l'information, c'est que justement c'est loin d'être une science exacte. Il n'y a jamais de bonnes et mauvaises solutions, c'est toujours un choix de ce qui semble être le moins mauvais.

Je dirais aussi que dans les ecoles, on apprend un langage mais on ne nous apprend pas a coder proprement.

Ca dépend des écoles. Il y en a de tout type. Celles qui enseigne des langages, celles qui apprennent à concevoir et gérer un projet informatique mais pas à coder... Moi je dirais que le plus gros problème, c'est que la majorité des développeurs (surtout en web) se sont auto-formés tout seuls dans leur coin et n'ont pas fréquenté la moindre école d'informatique du tout.
Ou alors, ils ont été formés il y a très longtemps et ont refusé d'évoluer ensuite.

Je ne pense pas que ca prenne beaucoup plus de temps de coder proprement. A mon avis, c'est inné. Il y a ceux qui sont fait pour coder proprement, et les autres qui baclent. Les perfectionnistes se font rares...

Je suis d'accord sur le fait que coder proprement ne prend pas plus de temps. Par contre ce n'est pas inné, ça s'apprend et ça prend du temps.
Et je dirais également que les perfectionnistes (disons surtout les puristes)sont tout aussi dangereux que ceux qui baclent leur code. Ils vous prennent la tête sur des détails sans intérêts, font perdre du temps par ce qu'ils ne savent pas s'écarter d'un modèle théorique pour passer à la pratique.
Bref, ils récitent un modèle par coeur sans en comprendre réellement l'esprit.

J'ai deja entendu mon maître de stage me dire de faire un diagramme de grant pour mes previsions sur le temps que je passerais sur le projet qu'il m'a confié, et puis m'avouer en toute franchise "les prévisions et estimations ne sont jamais respécté".
Pourquoi me demander de les faire si elles ne sont pas réspecter ???

Ben oui, par définition un planning c'est écrire ce qu'on ne fera pas .
Plus sérieusement, ça permet de ce donner une référence, de mesurer les dérapages du projet, de s'assurer qu'on possède la capacité à produire le reste à faire et d'initier les actions correctives lorsqu'on voit que ça dérape.
En théorie on devrait respecter le planning. Mais dans la pratique c'est quasi infaisable. Donc on pose des jalons, et on s'efforce de suivre le projet et replannifier régulièrement pour respecter ces jalons...

[Garulfo]

[...]En général, la phase de maintenance est plus longue que la phase de developpement. D'ou l'interet d'avoir un code propre des le début.[...]

Elle est surtout plus couteuse: 70% des efforts en moyenne.

[SlashEne]

Je n'ai jamais eu a maintenir un programme jusqu'à maintenant, je ne pensais pas que la maintenance était si importante que ca !

[HanLee]

Je vais prendre un example qui peut paraitre un détail insignifiant mais qui pour moi est révélateur. Par exemple, quand tu vois un entier, qui physiquement ne peut etre que positif, stocké dans un entier signé, tu te demandes pourquoi le codeur ne la pas stocké dans un entier non signé. La raison est que ca va plus vite d'écrire "int" que "unsigned int". Ensuite, celui qui passe derriere se demande pourquoi c'est baclé.

Juste pour revenir sur ça, le coup de l'unsigned int plutôt que l'int c'est pas forcément mieux.

Parfois ça m'a joué des tours. En OCaml, les "unsigned int" n'existent pas, que des int, ça n'empêche pas qu'il est en plus facile d'avoir un code correct qu'en C/C++/Java.

Le problème avec l'unsigned int, c'est que les entiers naturels, c'est que ça se comporte pas très bien avec les soustractions, c'est pas un groupe quoi.

Il arrive que tu joues avec les indices toujours positifs d'un tableau, dans des conditions qui peuvent être plus ou moins compliquées. Tu auras envie de simplifier des inéquations, équations, faire passer des indices de l'autre côté, et BOUM.

Tu comprends rien, mathématiquement, c'est correct, mais c'est tout simplement parce que les valeurs négatives n'existent pas...

[Franck SORIANO]

Le problème avec l'unsigned int, c'est que les entiers naturels, c'est que ça se comporte pas très bien avec les soustractions, c'est pas un groupe quoi.

Je ne suis pas convaincu. Un nombre négatif, c'est en réalité un nombre positif spécialement choisi pour que lorsque tu l'additionne à un autre nombre, ça fasse un overflow dont le résultat sera le résultat de la soustraction.
Nombre signé ou non signé c'est exactement la même chose. C'est les calculs sont les mêmes, c'est juste une information pour dire au compilateur comment il doit interpréter le résultat du calcul.

Je dirais plutôt que les gens utilisent des nombres signés parce qu'on leur a appris à programmer comme ça. Que mathématiquement, un entier ca peut être positif ou négatif donc on retient : entier = int. (ou entier = integer en pascal). Aller faire retenir à un débutant que entier ça peut être :
smallint, byte, shortint, word, integer, longint, cardinal, comp, int64...

Il y même des développeurs qui ne savent pas que les types non signés existent.

[Heaven2K8]

Mdr biensur que c'est grave,niveau sécurité on peut exploiter des failles dans ton codes

[tim974]

Salut, j'ai pas tout lu, mais dans les premiers messages tu dis qu'un chef de projet ne demande jamais de code propre...

Humm .. lorsque ton employeur te recrute, il te demande de prendre une douche tous les matins ?

Ce n'est pas la peine qu'il le demande, non? Tu le fais de toi même car c'est une chose normale. Le chef de projet, c'est pareil, lorsqu'il te recrute, il te demande de savoir coder bien et rapidement ( la propreté est inclut autant que faire se peut ).

Oui, je confirme que c'est 10 fois plus rapide de travailler avec du code propre, mais les normes changent tout le temps, donc la propreté du code reste relative selon les actions de maintenances effectuées.

[nicolofontana12]

Je crois que c'est la conception qui est plus interresant.Peux importe ( pas beaucoup ) la propriete du code

[mourbare]

Moi je suis aussi deja tombe sur des codes sales programmer par les professionnel du metier ayant plusieurs annees d'experience. Mais c'est fait aussi express. Quelques fois je le fais aussi. Pour que mon entreprise soit attacher a moi. Et ainsi meme en quittant l'entreprise, ils auront recours a vous.
Et voila une raison

[zaventem]

Je pense qu'une boite connu pour un développement de grande qualité (c'est à dire qui à beaucoup de client content) n'aura pas ce problème
et si c'est le cas il convient soit au chef de projet (je pense que c'est le meilleurs choix) soit aux commerciaux d'expliquer la situation.

Attention, tu idéalises encore. Un client est content quand tu lui livre ce qu'il veut quand il le veut. La qualité du code n'a RIEN a voir ici. (A de très rares exceptions près)

Idéalement une solution alternative serait de dire : "je ne peux pas respecter toutes vos spécification en pour T" cependant je peux vous livrer une version du produit tout les T/n, comme cela vous pourrez voir l'évolution du produit par vous même, le tester et nous donner un feedback.

En tant que client, je te répondrais peut-être : "Et bien moi, j'en ai besoin pour telle date. Si vous ne pouvez pas le faire, je serai forcé d'aller chercher ailleurs."
Les clients ne sont pas les êtres capricieux et inconstants comme on se plait parfois à les décrire. Ils ont aussi des obligations et des délais à tenir, des méthodes et des bonnes pratiques porpres à leurs métiers à appliquer.

Lorsque le produit vous plaira vous pourrez abandonner le projet à tout moment et nous payer juste pour le travaille effectué.
Si vous souhaitez des amélioration nous continuerons de travailler pour.
C'est le principe des méthodes agiles et je ne vois pas l'inconveniant ni pour l'équipe de dev, ni pour le client.

Moi je vois un gros inconvénient pour les équipes.
Tu planifie un projet, tu constitues une équipe, tu formes certains membres sur une techno particulière, t'engage un petit nouveau, tu achètes telle et telle licence, tu auras refusé un autre développement par manque de capacité de dev. mais sans avoir de garantie sur le montant que tu factureras?
Pourras-tu expliquer à ton équipe qu'elle ne sera pas payée parce que le client à choisit d'arrêter le dev?

Mais c'est fait aussi express. Quelques fois je le fais aussi. Pour que mon entreprise soit attacher a moi. Et ainsi meme en quittant l'entreprise, ils auront recours a vous.
Et voila une raison

Un développeur qui pense comme ça, je t'assure que je ferai ton mon possible pour qu'il dégage (et je pèse mes mots) le plus vite possible.
Si un dev. n'est pas capable d'être utile simplement par ce qu'il est capable d'apporter et que 'il se contente de te reposer sur ton travail passé, c'est un boulet!
Et tant qu'on y est, un DBA doit garder les mots de passe pour lui tout seul également?

[SlashEne]

Tu planifie un projet, tu constitues une équipe, tu formes certains membres sur une techno particulière, t'engage un petit nouveau, tu achètes telle et telle licence, tu auras refusé un autre développement par manque de capacité de dev. mais sans avoir de garantie sur le montant que tu factureras?

Attention je crois que l'on s'est mal compris, ce que je veux dire c'est que c'est le client qui voit l'avancement du projet en live, et qui peut arreter quand il veut.
L'equipe de dev sera payé en fonction du travail effectuer (par exemple un prix fixe par itération).
Le client pouvant demander d'arreter quand il le souhaite, et si c'est le cas il se contentera de payer les itérations passés.

[zaventem]

Attention je crois que l'on s'est mal compris, ce que je veux dire c'est que c'est le client qui voit l'avancement du projet en live, et qui peut arreter quand il veut.
L'equipe de dev sera payé en fonction du travail effectuer (par exemple un prix fixe par itération).
Le client pouvant demander d'arreter quand il le souhaite, et si c'est le cas il se contentera de payer les itérations passés.

Rassure-toi, je t'ai très bien compris seulement en entreprise on doit planifier les ressources sur un terme beaucoup plus long que la durée des itérations des méthodes "agiles". Tu ne pas pas dire: le mois prochain, si le client arrête, j'aurai 4 dev, 1 chef de projet et un DBA sur le carreau. Sur une grosse entreprise qui a une quinzaine de projets en parallèle, t'imagine la catastrophe si la moitié décide d'arrêter avant terme?

[SlashEne]

Tu ne pas pas dire: le mois prochain, si le client arrête, j'aurai 4 dev, 1 chef de projet et un DBA sur le carreau. Sur une grosse entreprise qui a une quinzaine de projets en parallèle, t'imagine la catastrophe si la moitié décide d'arrêter avant terme?

Si je t'ai compris, le gros problème ca serait que si il y a 7 developpeurs par équipe sur 14 projet different,
si 9 projets sont arrêtés on se retrouve avec 9*7 developpeurs sans boulot.
C'est vrai que ça peut poser problème...

J'ai compris ce que tu soulignes mais

la catastrophe si la moitié décide d'arrêter avant terme?

dans mon monde idéal il n'existerait pas de "avant terme" puisque le développement serait itératif, il n'existerait pas à l'avance de date butoir pour finir le projet (revenir sur ce que j'ai dit les derniers post).

Ce petit détails ne change de toute facon rien au problème que tu soulignes de la gestion des ressources (équipe de dev ici) sur le long terme.

Je dirais que l'on pourrait rajouter le surplus de main d'oeuvre aux autres projet qui continue de tourner en parallèle.

Mais si le prix que l'on soumet au client est basé sur un prix fixe / itération l'entreprise serait perdante....

Si le prix que l'on soumet au client est basé sur les fonctionnalité plutot qu'un prix fixe par itération, il y a ici un moyen de pallier ce problème.

Mais j'ai cru comprendre que dans l'informatique le fait de rajouter des membres dans une équipe peut ralentir un projet du fait que les nouveau prennent du temps pour arriver à leurs vitesse de croisière...(un livre très connu en parle The Mythical Man-Month).

Le fait d'appliquer un principe de Extreme Programming, qui dit que les développeurs doivent écrire les programmes en binome qui change à la fin de toute les itération ne peut t'il pas régler ce soucis ??(typiquement un developpeur confirmé et un novice, ce qui pourrait former le novice par la meme occasion à produire du bon code).