Discussion :

[SlashEne]

Notre direction a la plus grande difficulté à comprendre le fonctionnement de notre service de développement, le seul en fait avec une activité de bureau d'études et noyé dans un océan d'administratifs... Alors quant à leur parler de méthodes agiles, je crois que je ne vais même pas essayer ! Et je ne pense pas que ce que je décris soit un cas isolé, même si les situations peuvent légèrement varier d'une boite à l'autre.

Je comprend que la direction n'est pas apte à appliquer les méthodes agiles, ce n'est pas son métier après tout.
Mais n'y existe t'il pas une couche intermediaire entre l'équipe de dev et la direction (le chef de projet en locurrence). Le chef de projet pour moi est quelqu'un qui a suffisamment d'expérience pour appliquer les méthodes agiles à son equipe de dev, et peut expliquer dans le language de la direction les effets bénéfiques des projets agiles (leur expliquer juste la partie feedback et livraison toute les x semaines et les avantages qui en découlent, sans parler de la mise en oeuvre concrète sur l'organisatoin de l'équipe).

mais l'informaticien doit bien lui expliquer que les développements rapides ont un prix...

J'aime bien quand c'est dit comme ça, ca me fait pensé à certains jeu video ou l'on peut acceleré la production d'un batiment au détriment des ressources

[el_slapper]

(.../...)
Si je raconte cette histoire, c'est pour rappeler que le client ne voit peut être jamais le code, mais qu'il voit les factures. Au final, la décision lui revient, mais l'informaticien doit bien lui expliquer que les développements rapides ont un prix... Et surtout, dire "coûts de maintenance", "code sale", le client ne sait même pas ce que c'est.

mmmh, des clients inteligents, ça existe donc?

J'exagère, bien sur, mais j'ai vu un client qui avait 20 gugusses en régie sur un horreur inmaintenable lancer une refonte pour réduire l'équipe à 2 personnes(c'était possible). 5000 jours de forfait. Au bout de 1200 jours, le PDG a tout foutu en l'air (avec quelques autres projets) pour "faire plaisir aux actionnaires".

à 200 jours par an par personnes, et en comptant le consommé(qui avait été payé), le truc était rentable en 1 an. C'était début 2002. J'ai appris il y a une semaine qu'ils cherchaient des vétérans de l'application(sans doute pour une nouvelle tentative de refonte). Merci, sans moi.


Tout ça pour dire que parfois, la bonne conclusion s'impose, mais qu'après, l'intendance ne suit pas toujours

[GrandFather]

Le chef de projet pour moi est quelqu'un qui a suffisamment d'expérience pour appliquer les méthodes agiles à son equipe de dev, et peut expliquer dans le language de la direction les effets bénéfiques des projets agiles (leur expliquer juste la partie feedback et livraison toute les x semaines et les avantages qui en découlent, sans parler de la mise en oeuvre concrète sur l'organisatoin de l'équipe).

Ce que va surtout comprendre la maîtrise d'ouvrage à propos des méthodes agiles (je parle toujours dans le contexte d'un service de développement intégré à une boîte dont ce n'est pas l'activité), c'est que le feedback qu'elle doit rendre doit l'être rapidement pour que le développement progresse régulièrement... Et ça, généralement ça l'enquiquine bien. Tout au plus elle acceptera de valider une maquette ou un "proof of concept" au tout début du projet, mais pas de s'impliquer dans des itérations rapides.

Peut-être cela est-il différent dans une relation commerciale, le principe des jalons réguliers et validés des méthodes agiles "rassurent" le client et sont souhaités par lui. Mais dans une relation de service "non commerciale", il existe des facteurs structurels et culturels qui font que les solutions les plus "agiles" sont très difficiles à mettre en place.

La chose peut-être la plus difficile à admettre quand on débute professionnellement, et ce quel que soit le domaine, est que ce n'est pas toujours l'intelligence et le rationnalisme qui priment dans les organisations (et donc les méthodes de travail).

[souviron34]

La chose peut-être la plus difficile à admettre quand on débute professionnellement, et ce quel que soit le domaine, est que ce n'est pas toujours l'intelligence et le rationnalisme qui priment dans les organisations (et donc les méthodes de travail).

T'as ben raison

ce qui n'empeche pas d'etre justement frustre assez regulierement....

[SlashEne]

La chose peut-être la plus difficile à admettre quand on débute professionnellement, et ce quel que soit le domaine, est que ce n'est pas toujours l'intelligence et le rationnalisme qui priment dans les organisations (et donc les méthodes de travail).

J'y trouve encourageant moi, que malgrès tout ces "dévellopicides" des entreprises centré ou non sur le développement puisse quand même prospérer.

Moi qui aimerais bien créer une entreprise en sortant de l'école je me dis que si des entreprises avec des développeurs qui sont contraint (ou pas) à sortir du code pourri arrive à s'en sortir, je pourrais faire mieux !

Même si il n'est pas possible de toujours pratiquer les méthodes agiles, je pense que l'on peut toujours trouver un moyen de sortir un code avec lequel on pourra fièrement dire 3 ans après "c'est moi qui ai écrit ça" (j'ai pas dépassé les 3 mois... T-T).

Je pense que le pire de tout ca, ce n'est pas de devoir sortir de temps en temps du code pourri (apparemment nous y sommes forcement contraint un jour ou l'autre).
Le pire c'est de s'habituer à le faire, voir passer à longueur de journée du code pourri, être pressé comme un citron à longueur de journée au bout d'un moment on en devient forcement un développeur pourri (c'est contagieux).

La derniere fois que j'ai fait un code pourri je me suis dit comme prétexte "je suis obligé de faire pourri, car je réutilise du code existant déjà pourri", je regrette d'avoir penser comme ça je trouve que c'est à s'en degouter du développement (tellement dégouté que je n'ai plus ouvert visual studio pendant 2 jour de suite).

J'imagine que si vous êtes sur ce forum, vous n'êtes pas dégouté du développement et donc vous faites malgrès tout minimum 70-80% du temps un code avec les bonnes pratiques en têtes.

[Garulfo]

[...]
La chose peut-être la plus difficile à admettre quand on débute professionnellement, et ce quel que soit le domaine, est que ce n'est pas toujours l'intelligence et le rationnalisme qui priment dans les organisations (et donc les méthodes de travail).

Je dirais ça autrement. De plus en plus, les entreprises ou les industries savent ce que peux apporter et les dangers de l'informatique. Ne serait-ce que parce qu'en plus d'engager une équipe de développement, ils engagent parfois des conseillers distincts pour surveiller. Cependant, il est vrai que ce n'est que rarement l'intelligence et le rationalisme de l'informaticien qui prime : c'est l'intelligence et le rationalisme du capitalisme (sans sens péjoratif).

Je joins une histoire de Dilbert pour illustration

[_vince_]

Moi qui aimerais bien créer une entreprise en sortant de l'école je me dis que si des entreprises avec des développeurs qui sont contraint (ou pas) à sortir du code pourri arrive à s'en sortir, je pourrais faire mieux !

Je ne veux pas te decourager... mais le codage ne represente qu'une petite partie du developpement d'un logiciel (au sens large). Donc ecrire du code propre ne suffira pas a faire que ton logiciel aura du succes. Et meme si tu codes proprement, il y a aura toujours des bugs.

Si tu prends l'exemple du Concorde, ca a ete une reussite technologique mais un echec economique.

[GrandFather]

J'imagine que si vous êtes sur ce forum, vous n'êtes pas dégouté du développement et donc vous faites malgrès tout minimum 70-80% du temps un code avec les bonnes pratiques en têtes.

Il faut faire la part des choses entre ce qui est l'essence même de ton métier et les conditions dans lesquelles tu l'exerces. Dis-toi que les développeurs à l'origine de ce code pourri n'étaient probablement ni paresseux ni ignorants des bonnes pratiques, mais que le contexte dans lequel ils l'ont écrit ne leur a pas permis d'atteindre le niveau de qualité idéal.

Bien sûr il existe des développeurs peu rigoureux et peu au fait en matière de qualité, mais ils ne constituent pas à mon avis la majorité. De toute façon, Ils ne durent pas trop dans le métier, car le secteur est très concurrentiel et les développeurs, dont l'orgueil professionnel assez développé les font s'évaluer perpétuellement les uns par rapport aux autres, ne se font pas de cadeaux entre eux (les bonnes places sont devenues chères).

Cependant, il est vrai que ce n'est que rarement l'intelligence et le rationalisme de l'informaticien qui prime : c'est l'intelligence et le rationalisme du capitalisme (sans sens péjoratif).

C'est vrai d'une manière générale, mais dans beaucoup de grosses structures affligées de problèmes structurels, on est plus dans la Théorie du Chaos que dans le Malthusianisme (en référence à l'extrait de Dilbert) ...

[_Gabriel_]

Bonjour,

J'ai un peu l'impression d'arriver après la bataille. Ayant lu attentivement tous les messages, on pourrait grossièrement créer deux groupes :
- Les idéalistes déçus, voit ce qui se fait de mal et voudrait bien faire mieux
- Les réalistes fatalistes, sait que le mal existe est a appris à le maitriser (après avoir accepté son existence)

Je trouve dommage que le débat reste limité juste au code. Les problèmes cités concernent tout le cycle de vie d'un projet. Du premier contact client jusqu'à la mort définitive de l'ensemble logiciel produit.
Combien de projets sans (réel) cahiers des charges ? Combien de projet sans dossier d'analyse ? Combien de projet sans dossier technique ? Combien de projet sans dossier utilisateurs ? Combien de projets démarrés sans règlement de l'acompte ? J'en passe mais ces points sont aussi des facteurs qui influent sur le déroulement général du projet.

Concernant le code, il faut distinguer :
1 - le développement spécifique, on réalise quelque chose qui n'existe pas. Celui là est sujet à tous les risques. Rien que le fait de fournir un devis sur quelque chose que l'on a pas réalisé est déjà un problème mais c'est avant tout une réalité et l'expérience permet de plus ou moins rester dans le vrai. (C’est mon coté réaliste fataliste)

2 - le développement produit, on conçoit un produit qui sera distribué ensuite. Normalement, celui là reste moins sujet aux risques. On fait une étude d'opportunité, on évalue la faisabilité, on peut prendre le temps d'identifier un plus les risques.

Je pense que tous les messages ici faisaient surtout références au cas 1.

Bon finalement, je vais tenter de donner mon avis sur cette question mais avant tout je vais rappeler une certaine bonne pratique commerciale qui semble avoir été écarté de la discussion.
Quel que soit le projet (informatique ou non d'ailleurs), il y a trois caractéristiques fondamentales : budget, qualité, délai.
Le bon rapport commercial consiste à laisser le client en définir deux, le prestataire se sert du troisième comme variable d'ajustement.
Nous pouvons alors en déduire quelques pseudos relations mathématiques mais qui vont nous permettent de recadrer la question dans un contexte plus réaliste (+, - signifiant plus important, moins important en terme de volume)
- client: délais -, qualité + => prestataire : budget +
- client: budget +, qualité + => prestataire : délais +
- client: délais -, budget - => prestataire : qualité -
- .... et ca continue

Cette "règle" tend à rendre un rapport de force plus équitable. Concrètement, un client qui veut un produit pour hier, sans y mettre trop d'argent ne doit pas s'attendre à des miracles au niveau qualités parce que :
- humainement, ce n’est pas vraiment possible
- économiquement, un client voulant le beurre, l'argent du beurre, la crémière ... c'est un client avec qui on n'a pas vraiment envie de travailler sauf .... Un bon client, fidèle, mais qui a une urgence. Là il faut faire son maximum.

Là où les ennuis commencent c'est quand le commercial laisse le client définir les 3 points. La production doit juste se taire et essayer de faire quelque chose. C'est navrant ... mais ca existe bien souvent (le fameux mouton à 5 pattes)
J'ai lu qu'un code sale ne voulait pas forcément dire développeur incompétent. C'est vrai à cause des situations décrites plus haut.

Définitivement, ce que je dis et redis à mes développeurs, on ne recherche pas la meilleure solution car cela équivaut à la recherche de la vérité ... on choisis la solution la moins pire, celle qui fait le point moyen entre budget, qualités et délais.

Un chef de projet doit-il veiller à la qualité du produit qu'il gère ? Oui bien sur
Un chef de projet a t il toutes les compétences pour évaluer le niveau de qualités du produit qu'il gère ? Non, tout dépends de son profil.
Pour ma part, je suis chef de projet avec un lourd passif technique. Concrètement, j'ai le même niveau que les développeurs. Oui, pour moi c'est plus simple d'évaluer la qualité ou de justifier et d'accepter la non qualité du code produit.

J'ai trouvé un peu injustifié une généralisation sur le développeur "alimentaire" et le geek génial. Un développeur est une personne qui mets à disposition sa force de travail contre une rémunération. S'il fait son travail mais respecte les horaires, je ne vois pas où est le problème. Un développeur qui passe sa vie au bureau n'est pas non plus un geek génial.

Quand j'étais plus jeune, mon chef me disait que celui qui reste au bureau après l'heure a des problèmes d'organisations/compétence. Je pense que c'est vrai. Je pèse quand même mes mots. Que celui qui reste au bureau sans que sa charge de travail ne justifie réellement cet état, a des problèmes d'organisations/compétence.

Pour conclure, car je pense que je commence à être ennuyeux ;-), il n'y a pas de code sale ou propre, il y a un contexte dont tous les détails échappent au plus grand nombre, qui donne un résultat.
Pour une application ayant dés le début une durée de vie courte, faut-il passer du temps à faire un miracle de technologie ? Je ne pense pas. Pour une application qui doit durer quelques années, là par contre ce se discute beaucoup plus car bien évidement en maintenance ca paye tout de suite (en fait ca paye tout de suite pour celui qui maintient quelques années plus tard !!)

Par contre, la qualité est une affaire de tous. Pas besoin d'attendre son chef de projet pour s'efforcer de faire au mieux. La communication est aussi primordiale. Faire remonter les problèmes au chef de projet est essentielle mais faire redescendre et expliquer, recadrer le contexte vers les développeurs est tout aussi important. Je m'efforce de présenter un projet d'un point de vue fonctionnel mais aussi relationnel client, historique client bref que les développeurs sachent les détails de l'environnement du projet.

Pour rester scolaire, sachant que le client ne voit que l'interface et veut avant tout un produit fonctionnel, la fin justifie t elle les moyens (ou les non moyens) ?

[Garulfo]

[...]
Pour rester scolaire, sachant que le client ne voit que l'interface et veut avant tout un produit fonctionnel, la fin justifie t elle les moyens (ou les non moyens) ?

Le client ne voit que l'aspect fonctionnel lorsqu'il achète ton produit. Mais quand il devra le maintenir il verra le coût s'accroître si ça a été mal fait. De plus en plus de client sont d'ailleurs très prudent. Comme tout industrie, l'informatique se rationnalise dans ces procédures.

Donc même si, a priori, les tests d'acceptations sont les seuls choses importantes pour le client, il s'avère qu'un client risque de ne plus revenir chez toi si la prochaine fois tu lui fais payer le prix fort pour une maintenance simple.

[ZeRevo]

Quand j'étais plus jeune, mon chef me disait que celui qui reste au bureau après l'heure a des problèmes d'organisations/compétence. Je pense que c'est vrai. Je pèse quand même mes mots. Que celui qui reste au bureau sans que sa charge de travail ne justifie réellement cet état, a des problèmes d'organisations/compétence.

J'ajouterai que ça ne dépend pas forcément de lui. Il y a tellement de chose qui peuvent arriver au cours du développement. Un manque de compétence sur une technologie, une mauvaise appréciation de la manière de développer... Je sais pas vous mais moi des fois je fais des erreurs, et quand je les vois, j'essaye de les corriger et des fois c'est pas possible alors on cherche une solution.

Un dev peut rester bloquer sur un bug ou passer 3 heures à faire des recherches sans fournir une production de code. Il peut alors prendre du retard dans son code sans pour autant avoir cherché à perdre son temps.

[_Gabriel_]

Le client ne voit que l'aspect fonctionnel lorsqu'il achète ton produit. Mais quand il devra le maintenir il verra le coût s'accroître si ça a été mal fait. De plus en plus de client sont d'ailleurs très prudent. Comme tout industrie, l'informatique se rationnalise dans ces procédures.

Je suis d'accord. Je pense même d'ailleurs que par certains cotés, notre métier tiens un peu de la production artisanale (au sens vrai du terme, sans esprit péjoratif)
Cependant, quand je vois les pratiques de certains "gros" éditeurs de logiciels (interopérabilité nulle, driver payant en licence annuelle, ...), la prudence des clients ne s'expliquent pas uniquement avec cela.

Donc même si, a priori, les tests d'acceptations sont les seuls choses importantes pour le client, il s'avère qu'un client risque de ne plus revenir chez toi si la prochaine fois tu lui fais payer le prix fort pour une maintenance simple.

Je suis aussi parfaitement d'accord mais je pense qu'il faut avant tout replacer ta remarque dans un contexte économique (delai, budget, qualité)

J'ai eu à faire avec des projets qui d'emblée était jugé jetable, de moins à durée de vie courte. Dans ces cas , il faut s'adapter à la demande.
Pour ma part, je pense qu'un prestataire doit accompagner son client dans la réalisation de son projet mais aussi anticiper le futur. Cela fixe des contraintes (plus ou moins) qui impactent forcément le développement

[_Gabriel_]

J'ajouterai que ça ne dépend pas forcément de lui. Il y a tellement de chose qui peuvent arriver au cours du développement. Un manque de compétence sur une technologie, une mauvaise appréciation de la manière de développer... Je sais pas vous mais moi des fois je fais des erreurs, et quand je les vois, j'essaye de les corriger et des fois c'est pas possible alors on cherche une solution.

Un dev peut rester bloquer sur un bug ou passer 3 heures à faire des recherches sans fournir une production de code. Il peut alors prendre du retard dans son code sans pour autant avoir cherché à perdre son temps.

Oui, ok j'inclus cette situation comme une charge supplémentaire de travail. Cependant, l'aléas doit être le plus possible pris en compte dans le projet (identifier les problèmes, trouver des solutions avant de se trouver au pied du mur). Ceci dit, rester 3 heures sur un problème c'est peut-être déjà deux heures de trop. Dans mon équipe, on essaye de travailler en "ébullition". On considères qu'un problème bloquant sans solution ne doit pas bloquer une personne plus d'une heure. Au delà, il y a un effet de démotivation. Soit on laisse reposer le problème et on passe à autre chose pour y revenir ensuite avec un autre oeil (y compris avec l'aide d'autres dans l'esprit brainstorming), soit on met en place une solution secours (qui tient pour pouvoir passer à autre chose si le problème est vraiment bloquant) pour pouvoir y revenir dessus plus tard avec un oeil neuf (encore). Dans tous les cas, l'idée est de ne pas entrer dans une phase démotivante et que le problème d'une personne et l'affaire de tous, ne serait-ce que dans l'esprit de valoriser l'expérience commune.

[el_slapper]

Sauf que si tu ne passes pas un bon bout de temps à résoudre les problèmes, si tu ne te casses pas un peu les dents, tu ne progresses jamais. Les blocages peuvent être frustrants, mais ils obligent à pas mal de créativité, et à essayer tout un tas de trucs. Qui souvent ne marchent pas, mais connaitre ce qui ne marche pas est aussi utile que de connaitre ce qui marche.

Franchement, appeler à l'aide au bout d'une heure, alors qu'on a pas tout essayé, alors qu'on pense encore pouvoir résoudre le problème, moi je fais pas. Au bout d'une demi-journée, souvent, ma créativité est épuisée - et je demande. Mais dans le différentiel, j'ai beaucoup appris - et souvent résolu.

Après, ce délai dépend du type de problème. Si c'est pour dropper une table et que j'ai jamais fait sous ce système, je demande au bout de 5 minutes. Mais sur des problématiques algorithmiques complexes, naaaaaan, il faut se casser le crâne pour trouver. Et si ça démotive de chercher des solutions à des problèmes complexes, alors peut-être faut-il se demander pourquoi on fait ce boulot.

[_Gabriel_]

Franchement, appeler à l'aide au bout d'une heure, alors qu'on a pas tout essayé, alors qu'on pense encore pouvoir résoudre le problème, moi je fais pas. Au bout d'une demi-journée, souvent, ma créativité est épuisée - et je demande. Mais dans le différentiel, j'ai beaucoup appris - et souvent résolu.
.

euh l'un n'empêche pas l'autre. En fait je ne suis pas d'accord avec toi, pas tout à fait.

Dans l'ordre des choses (pour qui analyse son projet), on met en évidence les futurs problèmes (force/faiblesse de l'équipe, de son expérience) et on prends des dispositions pour trouver les solutions. Suivant le projet, il est peut-être même utile de faire une analyse de faisabilité avant de commencer à faire quelque chose.

Se trouver face à une impossibilité technique bloquante au niveau de code et qui oblige à revoir une partie de l'architecture, c'est déjà une erreur de conception ... euh attention, savoir comment "dropper une table" c'est déjà dans la liste des connaissances à acquérir décelées en pré analyse, avant même de répondre sur le devis.

Évidement c'est beau tout çà mais l'aléa est (toujours) là (;-) )
La créativité c'est beau mais dans mon monde, j'ai un client qui attends la livraison du produit, une direction qui attends des délais tenus, des développeurs qui attendent d'être payé. Être créatif ok, fana, mais en restant dans une certaine réalité économique, ou alors c'est de r&d. Il arrive qu'un aléas est était solutionné par une solution "moins pire" parce qu'un délais était là (ne veut pas dire code sale) et qu'on pris du temps en fin de projet ou après le projet pour revenir dessus car une meilleure solution est intéressante, surtout si le problème peut se représenter.

Ensuite la créativité peut-être collective. A qui ca sert de passer 4 h sur un bout de machin, alors qu'avec l'aide de son voisin en 30 minutes ça peut être résolus ...

Si tu entends créativité par créativité dans l'architecture, ca se passe en conception. Le code ne doit souffrir que de problème de code, pas de conception.

En gros savoir comment nous allons faire pour implémenter cette fonctionnalité, c'est en conception que cela se passe. Pas devant, son écran/clavier

Pour ce qui est d'apprendre, dans l'équipe, on privilégie l'expérience commune et le partage de l'information ... bon là on s'écarte du sujet.

Définitivement, on sait déjà que les délais seront courts, l'idée est donc de ne pas perdre de temps.

[Garulfo]

[...]
Je suis aussi parfaitement d'accord mais je pense qu'il faut avant tout replacer ta remarque dans un contexte économique (delai, budget, qualité)
[...]

Mais c'est justement dans un contexte économique... en moyenne, 70% des coûts d'un logiciel dans sa vie proviennent de la maintenance. De nombreuses études montrent que si plus d'efforts sont fait en amont (ingénierie des besoins), les coûts diminuent en aval (maintenance) de manière très importante.

Tu parles de projet jetable... mais ce sont des jouets. C'est négligeable. Une grande partie de l'industrie veut des solutions qui ne vont pas coûter des millions inutiles à entretenir. C'est le poids des clients qui a imposé la documentation et qui va la rendre encore plus importante. Les clients demandent maintenant les sources et la documentation complète (manuel utilisateur, manuel technique, code commenté etc.) pour contrôler l'avenir de leurs logiciels. On voit aussi de plus en plus l'appel à des conseillers externes se généraliser. Ils ont pour rôle de contrôler la qualité car le client lui-même ne peut la juger.

Donc en général, dans un contexte économique, sur des vrais projets industriels, il n'y a pas de discussion : il faut de la documentation et bien faite. Les temps changent l'industrie qui utilise l'informatique grandit et devient mature. C'était dans un vrai contexte économique que je me plaçais, avec des vrais problématiques pratiques. C'est de là que vient ce besoin. Pas des informaticiens eux-mêmes.

Finalement, en dehors de ces considérations, n'oublies pas que ne pas faire rapidement la documentation ou ne pas commenter le code, c'est en général prendre un risque important dans l'ingénierie des besoins, car tu risques d'oublier des besoins, ou de ne plus savoir faire de liens entre besoins <-> conception <-> morceaux de code. Je joins un graphique qui montre la catégorie de problème et leurs importances dans des développements de grands systèmes. On voit que les problèmes issus des besoins ou ceux issus d'une mauvaise documentation sont, proportionnellement, plus souvent majeurs que ceux issus de la conception ou du code (c'est dernier étant souvent négligeables). [ESPITI 1995]

Je t'en mets aussi une deuxième tiré de http://www.csdn.net/subject/JeremyDi...licseminar.pdf
Il montre que — ô surprise — un travail plus important en amont réduit les coûts. Encore une fois, « travail plus important en amont » veut dire « plus d'efforts sur les besoins et sur la documentation précoce comme les manuels utilisateurs ou les plans ».

Mais bon c'est vrai que quand je code moi-même un logiciel de quelques milliers de lignes, je ressens moins le besoin de tout ça. Par contre, le jour où on reprend nos projets (par exemple avec d'autres personnes) on se rend compte que si je ne voyais pas le besoin, il était là pourtant.

[_Gabriel_]

Exscuse moi, mais j'ai l'impression que tu me fais dire ce que je n'ai pas dit. J'ai justement dit et affirmé que la conception était une étape essentielle. Je ne dis pas non plus que tous les projets informatiques sont jetables. En fait je suis déjà convaincu par tout ce que vient d'écrire. J'ai juste replacé tout ce qui a été dit dans un contexte économique pour préciser que le code sale n'est pas uniquement du à des "je m'enfoutiste" mais bien que souvent la réalité est bien largement différente de la théorie, où "de ce qui serait idéal de faire".

Je viens d'en avoir encore un exemple ce mois ci. Un client qui migre son erp et qui viens nous demander de refaire deux applications en fonction de l'erp (changement de base de données, de structure, etc) en moins de trois semaines alors que nous l'avions prévenus qu'il fallait commencer à s'en préoccupé il y a plus d'un an? et ce n'est pas faute de l'avoir répété. Alors que faire dans ces cas là ? on refuse poliment de travailler ou on essai de faire le maximum ?
donc je ne dis pas que la documentation, une conception durable en amont, ... sont inutiles, je dis que c'est bien mais que dans la réalité ce n'est pas aussi rose que cela. Quelle que soit l'entreprise.

[Garulfo]

Exscuse moi, mais j'ai l'impression que tu me fais dire ce que je n'ai pas dit. J'ai justement dit et affirmé que la conception était une étape essentielle. [..]

On s'est peut-être mal compris alors ^_^
Sinon je ne parle pas de conception. La majorité des problèmes et des coûts vient de la phase d'ingénierie des besoins. C'est souvent cette partie qui décide si un projet échoue ou réussi. C'est donc avant même de commencer la conception que les problèmes sont présents.

[el muchacho]

J'ai "gueulé" quand j'ai vu la gueule de l'"architecture" de l'appli qu'on vient de mettre en prod (et il y a de quoi, tout est fortement couplé).
La hiérarchie a haussé les épaules. Maintenant que le département marketing du client a communiqué sur une feature qui s'avère ne pas fonctionner dans un cas précis, et que la correction n'est pas prête parce que quand on touche à un truc, ça pète ailleurs, et bien la même hiérarchie est en train de faire dans son froc. Ca leur fera les pieds.

[SesechXP]

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.

Normal, un code clair est plus facile à lire, plus agréable à développer, à maintenir, etc... et en plus tu en es plus fier

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.

C'est marrant ça me fait penser à mon futur ex collègue... Je devais porter des bibliothèques de logiciel embarqué qu'il avait écrites. Au final j'ai tout reconçu et redéveloppé car je ne comprenais rien à son chef d'oeuvre...

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.

Certains se contentent de faire un truc qui tombe en marche, ne sont pas exigeants avec eux-mêmes. Parfois aussi des méthodes à l'ancienne.

Moi non plus je ne comprends pas, pourtant j'ai écrit des choses pas terribles à mes débuts et je n'en suis pas fier . Il en reste un peu mais je rectifie le tir dès que je peux.

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

Je ne pense que ça ne doit pas être si rare que ça, au moins toi et moi en avons rencontré

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

Je ne sais pas si c'est dangereux pour une entreprise, mais certainement préjudiciable : ce n'est pas du tout motivant de bosser sur un code pourri. Quand on intervient dessus, on se dit c'est déjà pourri donc je continue... Et la maintenance est de plus en plus délicate.

Ou alors je refais tout, donc perte de temps pour l'entreprise. Quand l'auteur du code pourri se barre, la personne qui le reprend va galérer, perdre du temps à essayer de comprendre, et finir par le réécrire. Perte de temps également.

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 assez radical comme décision, parfois tu peux bosser à côté du logiciel pourri et faire des choses propres. Mais si tu es obligé de travailler avec, tu peux te poser la question...

++