Discussion :

[ac_wingless]

Le point difficile d'un chef de projet n'est pas de vérifier que le code est "bon", mais d'empêcher le zèle là où ça commence à couter plus que ça ne rapporte tout en osant dépenser des ressources en qualité de façon préventive, de sabrer les creeping features tout en détectant les non-dits du client, bref d'être subtil en plus d'être rigoureux.
N'importe qui sait fignoler une classe qui marche pas encore, n'importe qui sait torcher un bidule qui marche. Je dis aussi souvent "arrêtez de fignoler avant d'avoir commencé" que "et vous feriez ça chez vous?!?"
Dans une équipe, on a de tout, des incrustés ignorants et peu scrupuleux, des stagiaires surdoués fanatiques de telle ou telle méthode à la mode, d'autres ânonnant leurs design pattern pour des booléens, des seniors qui papotent jardin à la machine à café, d'autres qui viennent le week-end, des jeunes mamans qui sont submergées de tâches non professionnelles, etc.. Notre but, c'est que sur le projet en cours le client et l'employeur soient contents TOUS LES DEUX, et AUSSI, puisqu'on parle de "danger pour une entreprise", que l'équipe soit en bonne intelligence et performante pour le prochain projet. Ca veut dire que si vous étiez mon stagiaire, j'essaierais de vous embaucher (un jeune qui parle qualité!! je veux!!), mais avant je vous inviterais à prendre une bière un soir après le boulot, pour vous expliquer deux ou trois trucs.

La qualité du code, et sa distribution entre programmeurs et parties de projet, c'est simplement un des nombreux paramètres à gérer habilement pour respecter de multiples objectifs. Certainement pas le seul, mais peut-être le plus important, car on peut facilement foirer un projet en gérant mal cette qualité (trop "Bien" ou trop "Mal").

[Garulfo]

[...]e pourrais aussi prendre l'exemple des noms de variable qui ne respectent pas ce qu'ils sont sense representer.

C'est le meilleur exemple à utiliser.
Car il est souvent, d'une part, le plus simple à comprendre, d'autre part, déjà arrivé à quelqu'un qui a relu son code à un moment de sa vie.

[SlashEne]

Notre but, c'est que sur le projet en cours le client et l'employeur soient contents TOUS LES DEUX

Je ne sais pas si je suis idéaliste sur les bords (pardonnez ma jeune expérience !) mais je pense que le plus important pour un chef de projet c'est d'avoir :
-1 client content
-1 équipe passionnée et motivée.

Si malgrès cela l'employeur n'est pas content, il ne mérite pas d'avoir les services d'un si bon chef de projet.

Je suis d'accord pour t'accorder que le chef de projet a d'autre chat a fouetté que de savoir si le code est propre ou non (bien qu'a mon sens il doit être capable de l'apprécier).

Si un chef de projet n'a pas le temps d'apprendre a ses troupes de bien coder (ce que je comprend) je pense qu'une solution serait d'avoir un "mentor" au sein de l'équipe qui encadrerai les nouveau.
Le chef de projet se limiterai à savoir si ce mentor est un "vrai développeur" (a opposer au bidouilleur).
La relation qui existerait entre ce mentor et les nouveau serait dans le style prof/éleve.
Ne pensez vous pas qu'il faille mieux faire perdre à un mentor 50% de son temps pour apprendre aux nouveaux les bonnes pratiques et d'économiser 50% de la maintenance, plûtot que de galérer avec du code pourri qui met en boule non seulement les nerfs de ceux qui s'y confronte (et la motivation) mais aussi celle du client qui demande des nouvelles fonctionnalités ?
(le développeur prefère largement faire de nouvelle fonctionnalité que de corriger des bugs !... le client aussi).
Je pense que ça permetterait aussi d'améliorer la bonne humeur dans l'équipe.

Si je ne me trompe pas, ca m'a tout l'air d'une méthode agile.

Non ça c'est le b-a-ba de la gestion de projet. On définit des échéances et on fait en sorte de les respecter. Tout le monde sait que ce sont les échéances qui font avancer un projet. Sans échéances, ben pourquoi se presser, on a le temps de perdre du temps...

Frank ce qui m'avait l'air d'une méthode agile c'est que l'on pose des jalon et qu'on les réajuste toute régulièrement suivant l'avancement du projet

replannifier régulièrement pour respecter ces jalons

Car je pense que ca doit arrivé de temps en temps un planning qui planifie tout un projet sur 1000 jour.homme et qui fini au fond d'un placard.

En ce qui concerne le debat enflammé sur le unsigned int je pense que le bon plan pour départager serait de faire un

typedef int EntierPositif si il doit toujours être positif
typedef int EntierNegatif si il doit toujours être négatif :p
(remplacez le int par ce que bon vous semble :p)

Ca veut dire que si vous étiez mon stagiaire, j'essaierais de vous embaucher

il me manque quelques années avant de pouvoir être embauché mais en revanche j'aimerai bien être votre stagiaire (mais une grenadine plutôt qu'une bière )

[Franck SORIANO]

Je ne sais pas si je suis idéaliste sur les bords (pardonnez ma jeune expérience !) mais je pense que le plus important pour un chef de projet c'est d'avoir :
-1 client content
-1 équipe passionnée et motivée.

Si malgrès cela l'employeur n'est pas content, il ne mérite pas d'avoir les services d'un si bon chef de projet.

Tu n'as pas compris ce qu'est une entreprise. On est la pour se remplir les poches !!!! Le reste, ce ne sont que des moyens pour parvenir à ce but ultime.

L'employeur veut un client satisfait non pas par bonté d'âme, mais pour qu'il paie, pour qu'il achète et qu'il commande encore davantage.

L'employeur voudra une équipe passionnée et motivée parce qu'elle sera plus facile à gérer et probablement d'un meilleur niveau... pour être plus productive, ne pas dépasser les budgets, augmenter les marges.

Pour être sûr que le CP accordera bien une grande importance au respect des objectifs du projet, une part non négligeable de sa rémunération sera variable et conditionnée à l'atteinte de ces objectifs.

De plus, lorsque la taille de l'entreprise le permet, le CP a généralement assez envi de faire parti de la direction.

Frank ce qui m'avait l'air d'une méthode agile c'est que l'on pose des jalon et qu'on les réajuste toute régulièrement suivant l'avancement du projet

C'est que je me suis mal exprimé. Car on ne déplace pas les jalons. On réajuste les tâches à faire (qui fera quoi), on trouve de nouvelles ressources, pour faire en sorte que le jalon soit respecté.
Ca veut dire qu'on modifie les étapes intermédiaires pour atteindre ce résultat, pas qu'on réajuste les jalons.

[Alpha31]

Je ne suis pas un codeur comme vous, peut être un jour le deviendrai-je ...

En lisant cette discution, je n'arrête pas de me dire que la faute incombe premièrement et directement le programmeur ou le chef de projet ...

En effet je vois que le 1ier pb est la question du temps, la deadline arrive alors on fini a la va vite, pour le client ou le chef seul la partie visuel (donc pas le code) sera vérifié ...

Je pense que le problème vient finalement du fait que le programmeur préfère réalisé du code de merde et faire le faillot en finissant tant bien que mal dans les temps impartit, plutot que d'avoir les couilles de dire "Merde" au marketing, "Merde" au changement constant du a des décision fabulesque de politique et "Merde" a son chef de projet qui finalement lui aussi n'a pas les couilles de dire "Merde" a sa direction.

C'est finalement une histoire de (excusé moi l'expression) couilles molles !!!

Quand je vois tout ce stress, et toute cette merde crée uniquement dans le but de plaire a des décision fantasque des gens qui n'ont aucune idée de comment un soft/site est fait, qui n'en auront jamais, et dailleurs qui sont foutent royal et complet.

J'avoue que je ne comprend pas l'attitudes des developpeurs/Chef de projet.

Ils écrivent de la merde, habitue les autres fantasques a des temps réduit au minimum. Si vous arrivez a faire un projet en 2sem aujourd'hui, alors pour demain on vous en demandera 1 et ainsi de suite.

Si un soft developpé en 3 mois en demande 6, il y a bien un problème de responsabilité qui incombe le programmeur ou le chef de projet non ?

[el_slapper]

...sauf que l'informatique est une activité de soutien. Dans la plupart des cas, l'entreprise ne vit pas de l'informatique. Le métier, ce qui rapporte de l'argent, c'est le métier industriel, financier ou commercial de la boite. Pas l'informatique.

Les gens qui pratiquent le métier qui rapporte de l'argent constatent dans l'exercice de leur profession que certaines informatisations pourraient améliorer leur travail(au sens large). Donc ils cherchent une solution informatique, interne ou externe, à leur besoin. L'équipe projet n'est là que pour satisfaire un besoin - pas pour se faire plaisir.

Les interlocuteurs qui ne "connaissent pas l'informatique" font eux aussi face à des contraintes fortes - clients exigeants, fournisseurs fantasques, concurrents redoutables, réglementations tatillonnes, personnels pas toujours adaptables, etc..... Leur rejeter la faute, c'est trop facile.

Le projet informatique se doit de prendre en compte le contexte ou il est lançé. Certains besoins métiers peuvent évoluer rapidement, et l'outil informatique DOIT suivre. Au mieux. De bonnes méthodes et un personnel informatique sensibilisé à la nécéssité de coder proprement sont de gros plus, mais la première contrainte, c'est la contrainte métier. Extérieure au projet. Et qui, parfois, pousse à coder comme des gorets(il faut 10 jours - tu en as 2).

[SlashEne]

Tu n'as pas compris ce qu'est une entreprise. On est la pour se remplir les poches !!!! Le reste, ce ne sont que des moyens pour parvenir à ce but ultime.

Je ne suis vraiment pas d'accord sur ce principe.
Quand je ferais mon entreprise en sortant de l'école je bosserai pour rendre heureux le client et mon équipe (à supposer qu'un jour j'en ai une),

si je suis dans une entreprise ou tout le monde est stressé à en faire du code pourri pour qu'il sorte 1 mois plus tôt et pour finalement galérer comme pas possible pendant la maintenance, je quitterais simplement l'entreprise.

Une entreprise d'info avec des développeurs qui ne sentent pas que leur boîte est un endroit ou il fait bon vivre est aussi abérant qu'une entreprise avec des clients mécontents.

Et une boite avec des développeurs heureux passe avant tout pas un code propre où l'ajout de fonctionnalité prend le pas sur la maintenance curative.

Pareil pour le chef de l'entreprise je pense sincérement que sa motivation n'est pas de s'en foutre plein les poches, mais de faire évoluer son entreprise à mon sens la motivation de faire évoluer son entreprise est la même que celle d'élever un enfant : tu ne le fais pas pour avoir une retraite tranquille.

Une entreprise avec l'état d'esprit : "pour s'en foutre plein les fouille on sabote les employées" ne pourra pas s'en sortir car en partie, elle n'attirera pas les personnes douées.

Prenez l'exemple de Microsoft et Google ce sont des compagnies ou tous les employées (disons la plupart) savent que c'est un endroit ou il fait bon travailler.

Croyez vous vraiment que Bill Gates continuait à travailler a Microsoft pour s'en foutre plein les poches ??
Non c'est la motivation de voir son entreprise prospèrer et évoluer.
Je pourrais prendre le même exemple avec d'autre grande entreprise et personnalité de l'informatique.

Puis sincérement ne pensez vous pas qu'il est plus motivant de travailler en se disant "je vais faire quelque chose qui va changer le monde", "je vais faire en sorte que mon équipe et mon client soient heureux" que de se dire "je travaille pour gagner de l'argent" ???

Les personnes qui m'ont fait penser comme cela sont Joel Spolsky
et Guy Kawasaki.

Si j'ai compris ce n'est évidemment pas ce qu'il se passe dans la plupart des entreprises.
Mais je suis persuadé que c'est ce qu'il se passe chez les boites stars de l'informatique.

[SlashEne]

...sauf que l'informatique est une activité de soutien. Dans la plupart des cas, l'entreprise ne vit pas de l'informatique. Le métier, ce qui rapporte de l'argent, c'est le métier industriel, financier ou commercial de la boite. Pas l'informatique.

Pour moi tout le monde est aussi important dans une boite et je refuse de parler en terme de soutien.


http://www.fogcreek.com/About.html

At Fog Creek Software, management, not coding, is the support function.

Croyez vous que pour autant Fog Creek est un société qui va coulé ?
Je suis sur que non car ils attirent les développeurs compétents (Joel Spolsky étant pour moi ce qu'est Seth Godin pour les personnes du marketing).

Je veux dire par la que la seul présence d'une personne de ce rang (que ca soit dans le marketing ou dans le commercial ou dans le developpement)
dans une société permet de la faire passer à un niveau supérieurs aux autres.

Je suis entiérement d'accord avec Alpha31.
Le chef de projet doit savoir dire non aux commercials.

Je suis actuellement en stage dans une petite boite qui fait un logiciel très précis pour les hopitaux (ce n'est pas du developpement forfaitaire mais vente d'un service baser sur ce logiciel aux clients).

Ils répondent à toute les spécificités des clients et la ca commence à devenir un problème énorme.

Dans leur code d'installation de ce logiciel nous voyons des ligne de code dans le genre :

if(cNam = "toto") then installPackageSpecial("toto");

Ca devient inmaintenable et va vraiment commencer à devenir un grand problème...

[davcha]

une boite avec des développeurs heureux passe avant tout pas un code propre où l'ajout de fonctionnalité prend le pas sur la maintenance curative.

Une boite avec des développeurs heureux passe surtout par une boite où les développeurs sont payés.

Moi aussi je trouverais ça génial de vivre dans Startrek (*), mais en attendant je suis forcé, comme tous les autres, de faire avec et de gagner de l'argent, pour me payer de quoi vivre.

Travailler pour changer le monde, pour rendre les gens heureux, mais pas pour gagner de l'argent... Aucune entreprise, pas même microsoft ou google, ne fonctionne comme ça.
Travailler pour gagner de l'argent ET, accessoirement, changer le monde, pourquoi pas. C'est pas incompatible.

Pourquoi ceux qui travaillent pour gagner de l'argent seraient forcément incapable de faire autre chose que des logiciels à la conception douteuse en code spaghetti ?


Personnellement, il y a une chose que je remarque assez souvent (dans les PME en tout cas), c'est que les clients (que ce soient des patrons ou des employés) ont autre chose à penser que le développement logiciel. Normal, il faut bien qu'ils fassent leur boulot à eux.

Alors quand ils se rendent compte qu'un logiciel pourrait leur simplifier la vie, ils en font la demande souvent assez tardivement : du genre "ah il nous le faudrait pour avant hier, parce qu'il y a une nouvelle loi qui est passée avant hier et blablabla...".

Les clients qui s'y prennent bien à l'avance c'est plus rare, ça arrive plus souvent dans des cas où le client sait qu'il va y avoir un changement dans l'avenir (exemple la retraite d'une personne dans l'entreprise qui faisait un travail important dont la réalisation pourrait être simplifiée et accélérée par un logiciel, ne nécessitant plus personne d'autre que la secrétaire pour le réaliser). Dans un cas de ce genre, le client s'y prend souvent bien plus en avance, et ça laisse le temps de faire un truc merveilleux.

Mais le plus souvent, on a affaire à des clients qui ont besoin d'un logiciel tout de suite. Ce qui explique cette "frénésie" à écrire le programme le plus vite possible.

Dire "Merde" à son client, par contre, c'est une idée à la con. Sauf si on veut s'en débarrasser évidemment.


(*) : Jean-Luc Picard explique dans "Le Premier Contact" que la fédération, le "gouvernement" terrien global, a laissé tombé le modèle économique pour se focaliser sur des valeurs plus spirituelles. Et que par conséquent, la monnaie n'existe plus.

[_vince_]

if(cNam = "toto") then installPackageSpecial("toto");

J'ai vu pire comme code . Le nom de la fonction est comprehensible

[SlashEne]

davcha c'est évident qu'il faut gagner de l'argent, je ne dit pas le contraire mais je pense que c'est quelque chose qui viens naturellement lorsque l'on pense en 1er a faire plaisir au client et faire prospérer son équipe.

Pour moi l'argent fait parti des moyens de mener à bien ces deux objectifs (moyen necessaire mais loin d'être suffisante c'est sur !).

[davcha]

Comment comptes-tu "faire plaisir" à ton client quand celui-ci te demandera de réaliser un logiciel pour le mois prochain, alors que celui-ci nécessiterait 2 mois de dev, au moins, pour le faire "proprement" ?

[zaventem]

Pour moi tout le monde est aussi important dans une boite et je refuse de parler en terme de soutien.

Je trouve que ta vision idélise la place de l'informatique. Comme cela a déjà été indiqué, dans la plupart des cas l'nformatique est un "bonus", une valeur ajoutée et non le Core Business. Le meilleur exemple que je puisse donner est le mien, dans le procédure de DRP, seul l'infrastructure concernant l'accès même à la base de données est prévue. En cas de (très) gros problèmes, il s'en foutent complètement que les développememnts soit arrêter pendant le temps nécessaire à non trouver de nouveaux locaux (quitte à ce que cela dure un mois ou deux).

Le chef de projet doit savoir dire non aux commercials.

Dans mon cas, crois-tu qu'on puisse dire dire non quand la demande vient directement de notre ministre de tutelle?

[SlashEne]

Comment comptes-tu "faire plaisir" à ton client quand celui-ci te demandera de réaliser un logiciel pour le mois prochain, alors que celui-ci nécessiterait 2 mois de dev, au moins, pour le faire "proprement" ?

Je pense que le chef de projet est la pour cela, je pense que deja le projet partirait avec un pied dans le plâtre si le client vous donne un torchon en gise de spec et vous sort un "on veut ca dans 2 mois".

Si cela devait se produire soit je laisserais tomber le client, soit j'essayerai de lui expliquer les méthode agiles.

Je pense vraiment que les méthodes agiles peuvent intéresser le client...
Le fait de pouvoir dire "on vous livre toute les x semaines et on récolte votre feedback. Vous pouvez choisir d'arreter le developpement lorsque vous voulez, on vous livera alors la dernière version.".
De cette facon le client peut évaluer dès les premières semaines le temps de developpement du produit, de façon plus réaliste.

Si j'étais chef d'entreprise je n'aurais pas de temps à perdre avec des clients bornés (le stage que je fais actuellement ont plus de demande que de ressources nécessaire pour y répondre... je suppose que dans ce cas on peut se permettre de dire franchement a un client "je ne peux pas produire ce que vous me dite en 2 mois, mais je peux vous proposer de vous livrer toute les 3 semaines une version incomplete...")

Comme cela a déjà été indiqué, dans la plupart des cas l'nformatique est un "bonus", une valeur ajoutée et non le Core Business. Le meilleur exemple que je puisse donner est le mien, dans le procédure de DRP, seul l'infrastructure concernant l'accès même à la base de données est prévue.

zaventem, bien que je ne comprend pas tout ce que me dit, j'ai compris que tu travailles dans une société ou l'informatique n'est pas le métier "noyaux".
J'ai toujours eu des stages dans des entreprises très lier à l'informatique.
Mais si ils se foutent que le développement s'arrête pendant 1 à 2 mois je suppose que vous n'êtes pas "pressé comme des citron" et pouvez passer vous permettre de passer un peu plus de temps pour faire un code propre(bien que je suis certains que pour les developpeurs qui ont appris longuement a bien developper cela ne prend pas plus de temps...Mais en entreprise je pense qu'il faut un certain temps avant d'avoir une "vitesse de croisière" pour faire une equipe qui code proprement).

Dans mon cas, crois-tu qu'on puisse dire dire non quand la demande vient directement de notre ministre de tutelle?

Je n'oserais pas dire non c'est clair !

J'aimerai bien que tu me dises en termes clair pour moi, un peu plus sur comment se passe ton travail dans une entreprise dont l'informatique n'est pas son métier phare.

[el_slapper]

je ne parlais pas pour les éditeurs de logiciel; jamais bossé pour eux, et mon beau-frère n'aime pas en parler.

La boite que tu me présentes, c'est une boite qui s'appelle ***** Software. Pour eux, le logiciel est le coeur du métier. Comment ils marchent, je sais pas. Mais c'est pas la majorité des boites, loin s'en faut. Je parlais de soutien parceque c'est le boulot de la plupart d'entre nous. Que tu y échappes ne rend pas ton opinion plus universelle. Dans le cas général, le code produit n'est qu'un outil parmi d'autres.

Et même quand tu vends du logiciel clefs en main : c'est le client final qui achètes, utilise et décide. Si le client final décide que c'est important d'avoir un libellé sur 32 caractères que 25, et qu'il faut casser la bases de données pour ça, alors on casse la base de données. Ridicule? Ben non. L'informatique n'a aucune valeur en tant que telle. Elle n'acquièrt de la valeur que si elle aide les agriculteurs/banquiers/médecins/militaires/autres à faire leur boulot.

Et ce ne sont pas de basses considérations comme la beauté du code ou le plaisir du programmeur qui doivent compter. Seul compte l'aide apportée à l'utilisateur final. Ca donne parfois des codes plus difficilles à maintenir, mais si on fait ce que veut le programmeur, ben l'utilisateur, il met le programme à la poubelle.

Dans ton cas hospitalier, oui c'est couteux de mettre une pustule qui gère tel client de manière différente. Mais si c'est fait proprement, et que c'est facturé, ou est le problème?????


P.S. : ça n'empêche pas de faire le code le plus propre possible. Mais il s'agit quand même de répondre à un besoin. D'abord.

[davcha]

A propos de "code propre", "conception nikel" vs "code spaghetti", "conception merdique"...

En imaginant que d'un côté comme de l'autre, les deux codes et les deux conceptions soient équivalentes en ce qui concerne les performances et la fiabilité.

La conception nikel, le code bien propre aura surtout un intérêt vis à vis de la maintenance du logiciel (ce qui inclut l'évolution du logiciel).

Est-il, alors, autant nécessaire d'avoir un code propre et une conception nikel quand on sait que le logiciel n'évoluera pas (ce qui peut arriver, pas souvent, mais ça arrive) ?


Tout ça pour dire que "le code propre", "la conception nikel" ne sont pas des valeurs qui intéressent directement le client.
En réalité, "le code propre" et "la conception nikel" ne sont vraiment intéressantes que pour l'équipe de développement : grâce à un code propre et une conception nikel, ils vont être capable de faire la maintenance logicielle très rapidement, avec un minimum d'effort. Donc avec un minimum de coûts, et tout ce que ça entraine (compétitivité, réactivité, etc..)

Or, ce que recherchent les clients, c'est avant tout des logiciels qui marchent, qui s'adaptent à leur besoins et livrés rapidement à des coûts réduits (ou tout du moins à des coûts maîtrisés).

Et c'est bien ce que permet une conception et un code "propre", dans le cadre d'un contrat avec beaucoup de maintenance derrière.

[zaventem]

J'ai toujours eu des stages dans des entreprises très lier à l'informatique.Mais si ils se foutent que le développement s'arrête pendant 1 à 2 mois je suppose que vous n'êtes pas "pressé comme des citron" et pouvez passer vous permettre de passer un peu plus de temps pour faire un code propre(bien que je suis certains que pour les developpeurs qui ont appris longuement a bien developper cela ne prend pas plus de temps...Mais en entreprise je pense qu'il faut un certain temps avant d'avoir une "vitesse de croisière" pour faire une equipe qui code proprement).

Détrompe toi, ça n'a rien à voir... On est toujours "pressé comme des citron".
C'est simplement qu'en cas de très graves problèmes (par exemple si le bâtiment venait à subir un grave incendie) les développements ne feront pas partie des priorités. D'abords on fait ce pourquoi l'entreprise existe, les améliorations et les nouveautés viennent après. Chez nous c'est dans l'ordre: assurer l'accès à la DB, rétablir les téléphones, les emails et ensuite seuelement on se posera la question de savoir comment reprendre les développements.

Je n'oserais pas dire non c'est clair !

J'aimerai bien que tu me dises en termes clair pour moi, un peu plus sur comment se passe ton travail dans une entreprise dont l'informatique n'est pas son métier phare.

Ben, je sais pas quoi te dire... Comme dans presque toutes les entreprises, on slalomme entre les obligations légales, les besoins urgents des utilisateurs, les visions "stratégiques" de la direction du sommet, les retards d'une sorte et d'autres,... pour fournir ce qu'on nous demande. Ce qui compte c'est que cela fonctionne, le reste tous les non-informaticiens s'en balancent.

[zaventem]

Une petite anecdote encore (pourquoi est-ce toujours après avoir envoyé le message qu'on y pense?)

Je maintiens à l'heure actuelle une application web cruciale en ASP. La première mouture a été écrite en 1999 par une personne autodidacte, sans documentation bien entendu. Avant moi, trois où quatre personnes y sont passées, chacune ayant mis ses rustines (presque toujours en dépit du bon sens) pour l'adapter à l'évolution des besoins - dont le moindre n'est pas d'avoir vu la quantité de données à traiter être multipliée par 20.
A l'heure actuelle, chaque petite modification me prend un temps dingue et je prie à chaque fois pour que cela ne casse rien d'autres. La seule solution serait de tout réécrire de A à Z. Au vu du temps passé dessus depuis le début de l'année, j'aurais pu l'avoir refaite au moins deux fois, la seule chose qu'il faudrait c'est une demande officielle du service qui l'emploie.

La seule réponse que nous avons eu à chaque fois que nous l'avons proposé c'est :"Mais pourquoi tout refaire puisque ça fonctionne?"

C'est ça l'aspect support (enfin, le mauvais coté).

[SlashEne]

Si le client final décide que c'est important d'avoir un libellé sur 32 caractères que 25, et qu'il faut casser la bases de données pour ça, alors on casse la base de données

Pour moi c'est un exemple de mauvaise conception si le développeur à bien fait son code le fait de passer de 32 a 25 nécessite de changer 1 valeur dans le code (voir dans le fichier config de l'application du client sans recompilation).

Je trouve que c'est mal de penser "il y aura peu de maintenance, puis le client ne voit pas le code donc je peux y aller crado".

Le bon développeur code propre sans avoir a passer des heures et des heures en conception (pour un petit projet de 1 ou 2 mois.homme il peut y penser dans les transport en commun jusqu'à son boulot).

pour moi en ordre de grandeur sans parler de maintenance, à niveau technique égal est de :

-un développeur qui produit du bon code passe 3h min pour faire une tache X.
-un développeur qui code au feelings sans aucun principe prendrait 4 à 5h.
-un développeur qui essaye de produire du bon code (phase d'apprentissage)
prendrai 6 à 7 h

Ca prend du temps d'apprendre à appliquer judicieusement les patterns et même simplement savoir utiliser la POO de la bonne manière peut prendre des années d'expériences.

Les débutants qui feront perdrent le temps des seniors pour un projet A sera largement récupérer dans le projet B.
Ce débutant la sera reconnaissant de ce qu'il aura appris et content d'être dans cette entreprise.

Si le client me demande de faire quelque chose de plus dans les spécifications et que je sort du code sale pour le faire rapidement, je me dit toujours : "si je dois coder sale pour aller vite c'est que j'ai mal conçu la chose dès le début".
Je cherche comment est-ce que c'est arrivé, et faute de temps je laisse mon code pas forcement propre en me disant : la prochaine fois je ne ferais pas la même erreur.

Ce genre de chose ne m'arriverai pas si j'avais un mentor en temps que maitre de stage qui puisse me dire directement ce qui ne va pas.

Mais une chose est sur plus j'en apprends (que ca soit dans les bonne pratiques, conception, ou aspects techniques), plus j'aime développer, plus je suis rapide, plus j'arrive à faire des choses que je croyais compliqué avant facilement.

Et une chose est sur : mon code est toujours pourri 4 mois après que je l'ai écrit. Je me dit que je progresse de plus en plus. Mais il est de toute facon moins pourri que la classe à 60 méthode 3000 lignes de mon maître de stage.

La question d'écrire proprement est à mon sens ni une question de temps, ni une question de necessité mais une question d'évolution de soit même et de son équipe.

J'aimerai vraiment savoir si les boîtes comme IBM, SUN, Microsoft, Google ou Apple, tolère un code pourri pour une question de rapidité.

Pour moi un code propre permet aussi de faire des choses plus compliquer car il réduit l'écart des représentations (je pense que tout le monde est de mon avis pour ca).

L'informatique n'a aucune valeur en tant que telle. Elle n'acquièrt de la valeur que si elle aide les agriculteurs/banquiers/médecins/militaires/autres à faire leur boulot.

Tout à fait d'accord

Dans ton cas hospitalier, oui c'est couteux de mettre une pustule qui gère tel client de manière différente. Mais si c'est fait proprement, et que c'est facturé, ou est le problème?????

Le problème c'est qu'ils passent du temps pour des spécificiation et correction spécifique de leur logiciel pour chaque client.

N'est t'il pas plus intéressant de passer son temps à implémenter des spécifications pour le logiciel qui s'applique a tout les clients, et qui limite la corrections de bug spécifique au client X ?

[zaventem]

Pour moi c'est un exemple de mauvaise conception si le développeur à bien fait son code le fait de passer de 32 a 25 nécessite de changer 1 valeur dans le code (voir dans le fichier config de l'application du client sans recompilation).

Je vais retourner le problème: passer de 25 à 32 caractères. Tu ne vois toujours pas de problèmes qui pourraient se passer? Imagine par exemple que ce texte soit utiliser pour sortir des documents... Çà ta conception ne peut rien y faire.

Je trouve que c'est mal de penser "il y aura peu de maintenance, puis le client ne voit pas le code donc je peux y aller crado".

Personne n'a dit cela il me semble, ce que l'on essaye de te faire comprendre c'est que par moment la question est "on a 2 mois pour faire ceci, il nous en faudrait 3. Que peut-on sacrifier pour tenir le délai?"

Si le client me demande de faire quelque chose de plus dans les spécifications et que je sort du code sale pour le faire rapidement, je me dit toujours : "si je dois coder sale pour aller vite c'est que j'ai mal conçu la chose dès le début".
Je cherche comment est-ce que c'est arrivé, et faute de temps je laisse mon code pas forcement propre en me disant : la prochaine fois je ne ferais pas la même erreur.

Ou que les spécifications ont changées, où qu'une personne de l'équipe est tombée malade,... Il y a tellement de facteurs pouvant intervenir.
J'ai, il y a déjà un bout de temps, développé un outils tout à fait stupide qui allait ne servir qu'une seule fois. Je n'allais surement pas passer deux heures à penser à ses éventuelles possibles évolutions qu'on pourrait y apporter s'il n'avait pas été jetable. (autant le faire à la main alors)
Pas de bol, il a continuer à servir. Tant pis pour le code qu'il y a dedans.

J'aimerai vraiment savoir si les boîtes comme IBM, SUN, Microsoft, Google ou Apple, tolère un code pourri pour une question de rapidité.

Je parierais que oui, comme partout. Probablement pas dans les applications destinées à être diffusée mais pour les développements en interne et non critiques, cela doit surement se produire

N'est t'il pas plus intéressant de passer son temps à implémenter des spécifications pour le logiciel qui s'applique a tout les clients, et qui limite la corrections de bug spécifique au client X ?

Pas si le client X paye assez pour voir ses demandes traitées en priorités.