Discussion :

[mumen]

A moins que, forts de l'expérience des 40 années précédentes

+1 global. Comme souvent d'ailleurs.

Tu vis et décris ce que je disais dans un post sans doute étrange : être un programmeur sur le terrain, c'est pratiquer une activité irrationnelle.

A cela il faut bien sur ajouter que l'être irrationnel a extrêmement mauvaise presse dans notre civilisation de l'ordre.

Ok je sors.
a+

[mumen]

La génération de code c'est un pis aller, une impasse. Tout le monde en fait, personne n'y croit. Chacun développe sa moulinette dans son coin et peste quand son client lui dit qu'il faut revoir tout son bazar. Evidemment, générer du code c'est une contradiction grossière avec la loi majeure du développement en cours : ça bouge tout le temps. Et ne parlons pas du RAD-OBJET qui est complètement autiste avec la donnée, qui est considérée pour ce qu'elle n'est surtout pas : une abstraction dont on pourrait faire abstraction.

Le vrai développeur est infabriqué et infabriquable par les distinguées écoles de grosses têtes. C'est une deuxième impasse.

Le néo-pseudo-développeur qui "manage" des gigas de bibliothèques et frameworks pour dire son hello word pas comme les autres est dans l'impasse. Et de trois.

Entre les "vieux" beaucoup plus formés à la dure sur le tas qu'en théorie et les "jeunes" finalement pas formés du tout pour affronter le vrai problème, "jeunes" parmi lesquels plus personne ne semble pouvoir naître à ce métier un poil fantasque ou l'on peut, selon l'humeur de madame, le temps qu'il fait, ou l'age du capitaine, boucler une tâche lambda en deux semaines ou en deux heures, incluant une pause café, c'est ça ce métier. A moitié imprévisible.

L'impasse de l'ingénierie en informatique de développement, c'est cette imprévisibilité impensée et donc imprévue. L'impasse du développement "moderne", c'est de croire que l'on peut commander l'invention. C'est exactement le même processus de blocage progressif qui a lieu beaucoup plus lentement, mais puissamment dans la recherche scientifique.

La réalité, c'est que ce tout jeune métier est en crise. C'est normal. Ça grandit. On va devoir prendre le temps d'arrêter d'avancer à fond un petit peu, prendre le temps de regarder. Voyez Dot Net. Magnifique en théorie, c'est un monstre sans tête. A Microsoft qui avait des centaines de millions de développeurs en VB / VBA à la fin des années 90, il reste quoi ? Il court maintenant après les développeurs WEB et saborde VBA depuis 2000 ! La misère quoi. Et le développement WEB ? C'est quoi en terme de qualité de développement ? Une abominable régression bien sur. Fin 90 on avait des dizaines de façons dont certaines magnifiques et matures de programmer professionnellement. Maintenant on en a des milliers d'immatures et changeantes comme la mode !

Un cycle se termine, un autre commence. On s'aperçoit des erreurs et on les corriges. Oh ça peut être long par rapport à une vie d'homme. Mais on corrigera. Parce que en tant que corps de métier on est des vrais jeunots.

Quand je vais chez certains de mes clients (équipementiers, ferronniers industriels), il y a un bureau d'études avec sur les PC, Autocad ou Katia dessus. C'est un bureau avec de gens fort différents des administratifs, des commerciaux, des productifs. Ils sont négligés, cools, on n'ose pas trop les remuer de peur qu'ils ne perdent la foi. Ils sont en contact avec la machine à venir, qu'ils inventent en 3D sur leurs écrans géants. Ce sont des codeurs. Leur intégration est réussie, répétée. Leur salaire est correct, ils sont respectés, voire bichonnés, eu égard à leur sensibilité.

La différence entre leur métier et le notre ? L'informatique est pour eux un outil de plus dans un métier stable et aux origines plusieurs fois centenaire. Alors que pour nous, le métier est né il y a quelques décennies d'un outil qui n'a depuis jamais cessé de changer, révolutionné plusieurs fois par ans qu'il est.

[rmaker]

La différence entre leur métier et le notre ? L'informatique est pour eux un outil de plus dans un métier stable et aux origines plusieurs fois centenaire. Alors que pour nous, le métier est né il y a quelques décennies d'un outil qui n'a depuis jamais cessé de changer, révolutionné plusieurs fois par ans qu'il est.

Je ne cite pas l'intégralité du poste, bien que j'y adhère. Sauf sur cette partie. Dans les détails, du fait de l'informatique, ces métiers aussi sont en cours de mutation. Les grandes lignes sont les mêmes depuis des années.

Et bien, informaticien, c'est pareil, sur une échelle plus courte. Notre métier se réinvente tout le temps, certes. Les techniques et les modes passent, certes. Personnellement, j'ai connu C++, Java, et maintenant C#. On sera amené à passer du web au client lourd, du C# à groovy, d'un ORM au bon vieux SQL, etc.

Mais, ce n'est pas notre métier. Notre métier, c'est de produire un système pour le client, en fonction des exigences de sa DSI, et plus généralement du contexte. Notre travail, c'est une façon d'appréhender une technologie, un problème, ou notre client (qui pour certains est aussi une source de problèmes). Au bout d'un temps, ce sont des principes qu'on applique encore et encore, au mieux en fonction d'une technologie ou d'une autre. Bref, on s'adapte, on rend notre client heureux, on prend plaisir à coder. Et ça, ça n'a pas changé depuis des années.

Tout çà pour dire qu'on va continuer à coder, mais pas forcément dans le même langage.

[souviron34]

Mais, ce n'est pas notre métier. Notre métier, c'est de produire un système pour le client, en fonction des exigences de sa DSI, et plus généralement du contexte.

Tu peux oublier le reste : ce n'est vrai que dans des grosses soicétés et dans les SSII...

Et c'est en ça que je soutiens que, contrairement à ce que toutes les technologies, métodlogies, et pédagogies veulent nous (enfin plutôt vous) faire croire, nous sommes et resteront des artisans, comme , bien que des gens achètent chez Ikea, il reste des menuisiers, et on en aura toujours besoin... et bien que on achète des machines (ou des voitures), on est bien content de trouver un dépanneur ou un garage...avec un éléctricien ou mécano qui s'y connaisse...

[el_slapper]

Tu peux oublier le reste : ce n'est vrai que dans des grosses soicétés et dans les SSII...

Ta formulation est ambigue. Je suppose que pour toi, l'important c'est "Notre métier, c'est de produire un système pour le client", mais je ne suis pas sur de t'avoir bien compris.

Et c'est en ça que je soutiens que, contrairement à ce que toutes les technologies, métodlogies, et pédagogies veulent nous (enfin plutôt vous) faire croire, nous sommes et resteront des artisans, comme , bien que des gens achètent chez Ikea, il reste des menuisiers, et on en aura toujours besoin... et bien que on achète des machines (ou des voitures), on est bien content de trouver un dépanneur ou un garage...

+1

Avec une différence majeure. Notre IKEA à nous, ce sont les logiciels distribués partout - et ils sont AUSSI réalisés par des artisans, parceque le cout de duplication est dérisoire. Dans le meuble, un industriel produit le meuble IKEA/FLY/ALINEA(pour ne pas faire de jaloux), mais un artisan produit le meuble de qualité. Dans le logiciel, un industriel produit de la merde inutilisable, et un artisan produit un élément de qualité, fut-il formaté pour le plus grand nombre ou taillé sur mesure.

Je ne crache pas sur la démarche industrielle. Elle est utile dans bien des domaines : gestion de version, distribution des executables, gestion des serveurs, encapsulation des éléments techniques, et j'en oublie. Mais pour la création de l'executable fonctionnel, elle est contre-productive : un code, c'est une description complète de comportement exhaustif; c'est un acte de création. C'est un acte forcément individuel(quitte à utiliser plusieurs individus, comme on utilise plusieurs graphistes pour un dessin animé).

[souviron34]

Ta formulation est ambigue. Je suppose que pour toi, l'important c'est "Notre métier, c'est de produire un système pour le client", mais je ne suis pas sur de t'avoir bien compris.

?? J'ai souligné ce qui était important et référé au reste via justement le terme "reste"

Un café peut-être ??

Avec une différence majeure. Notre IKEA à nous, ce sont les logiciels distribués partout - et ils sont AUSSI réalisés par des artisans, parceque le cout de duplication est dérisoire.

Euh.. T'en connais beaucoup de logiciels inondant la France ou le monde et fait par un gars dans son coin ???

Pour inonder, il faut du marketing.. et de la vente..


Par conte, j'ai zappé le fin de la denrière phrase de mon post :

Au lieu de :

et bien que on achète des machines (ou des voitures), on est bien content de trouver un dépanneur ou un garage

ça aurait dû être :

et bien que on achète des machines (ou des voitures), on est bien content de trouver un dépanneur ou un garage, avec un éléctricien ou mécano qui s'y connaisse

Je vais corriger ça

[infofree]

Tu peux oublier le reste : ce n'est vrai que dans des grosses soicétés et dans les SSII...

Et c'est en ça que je soutiens que, contrairement à ce que toutes les technologies, métodlogies, et pédagogies veulent nous (enfin plutôt vous) faire croire, nous sommes et resteront des artisans, comme , bien que des gens achètent chez Ikea, il reste des menuisiers, et on en aura toujours besoin... et bien que on achète des machines (ou des voitures), on est bien content de trouver un dépanneur ou un garage...avec un éléctricien ou mécano qui s'y connaisse...

Moi je dis plutôt que la différence sera au niveau de la qualité et des coûts de fabrication (et donc forcément des tarifs de vente derrière)
On peut avoir une armoire Ikea à monter soit même à 400 ou 500€, (qui n'est pas forcément mauvaise), comme on peut avoir l'armoire équivalente (en terme de dimensions, design ... ) faite par un menuisier de métier et qui a mis un certain temps pour la "fabriquer" avec un coût des charges et des matières premières plus élevé, et qu'il vendra donc 1500, 2000 ou 3000€

Après, c'est au client/consommateur de faire le choix, selon son budget, l'utilisation qu'il veut en faire etc

[souviron34]

Moi je dis plutôt que la différence sera au niveau de la qualité et des coûts de fabrication (et donc forcément des tarifs de vente derrière)
..
Après, c'est au client/consommateur de faire le choix, selon son budget, l'utilisation qu'il veut en faire etc

Si c'était si simple, ça se saurait...

On peut avoir une armoire Ikea à monter soit même à 400 ou 500€, (qui n'est pas forcément mauvaise), comme on peut avoir l'armoire équivalente (en terme de dimensions, design ... ) faite par un menuisier de métier et qui a mis un certain temps pour la "fabriquer" avec un coût des charges et des matières premières plus élevé, et qu'il vendra donc 1500, 2000 ou 3000€

Exact, sauf que ton armoire IKEA, au bout du 2ième ou 3ième déménagement, à la remonter et démonter, les boulons vont patiner, les étagères vont plus être tout à fait droites, les tiroirs ne plus fermer tout à fait, etc etc.. Et dans 15 ans, elle part à la déchetterie..

L'autre meuble, tes arrières-arrières-petits-enfants pouront toujours s'en servir... Soit une économie de ....... 60 ans (durée de vie moyenne d'un adulte) / 15 ans (durée de vie l'amoire IKEA) * 5 (générations).... = environ un facteur 25... diivisé par 3 pour la différence de coût à l'achat, reste encore un facteur 8...

Et encore le 5 est un minimum.... (et le 15 est très optimiste) Les meubles anciens ont facilement 2 ou 3 siècles...

Donc pour faire des économies à court terme tu dépenses 1.25 fois plus à long terme.. (si tu penses uniquement à ta vie)(sans compter le temps perdu dans les magasins à chaque fois, plus éventuellement les frais de livraison) et au minimum 8 fois plus si tu prends en compte les générations qui suivent..

Mais c'est bien dans le cadre de la société actuelle...

Et c'est exactement ce qui se passe en info...

[rmaker]

Moi je dis plutôt que la différence sera au niveau de la qualité et des coûts de fabrication (et donc forcément des tarifs de vente derrière)
On peut avoir une armoire Ikea à monter soit même à 400 ou 500€, (qui n'est pas forcément mauvaise), comme on peut avoir l'armoire équivalente (en terme de dimensions, design ... ) faite par un menuisier de métier et qui a mis un certain temps pour la "fabriquer" avec un coût des charges et des matières premières plus élevé, et qu'il vendra donc 1500, 2000 ou 3000€

Après, c'est au client/consommateur de faire le choix, selon son budget, l'utilisation qu'il veut en faire etc

Alors, je ne veux pas faire mon vieux con raciste, mais pourtant... J'ai bossé avec une équipe de R&D en Tunisie, et une en Inde. Ce sont les deux pires expériences de ma vie. Vraiment. J'ai l'impression qu'on va glisser sur un débat vers l'offshore, mais c'est bien de ça dont il est question.

Du coup, si je devais généraliser, je dirais que, chez Ikea comme dans le développement, tu as la qualité pour laquelle tu as payé. Si tu ne veux mettre que 100€ dans une armoire, tu sais déjà qu'elle ne te fera pas 5 ans, plutôt deux. Si en revanche, tu veux du chène qui te fera toute ta vie, alors là il va falloir payer.

Ce qui m'amène à penser que c'est plus compliqué. D'expérience, tu as un "grand esprit du management", qui n'a jamais vu un développeur de sa vie, qui compare comptablement deux solutions sur la seule base du cout: c'est pas cher, on engage, on fait! Et c'est répercuté jusqu'aux chefs de projets qui vont bosser, sans qu'on ne leur demande rien, en offshore. Ou avec des développeurs mauvais mais pas chers. Et, comme d'habitude, ce sera au chef de projet de serrer les dents, de faire avec, de satisfaire ses clients. Mais lui / elle le sait bien que çà va être plus dur, moins bon, et que les clients vont râler. D'expérience, toujours, cette idée d'aller au moins cher, ça dure quelques années, et puis, devant la merde que devient le logiciel, on arrête les frais et on relocalise.

Je n'aime pas ce post aux allures de nationalisme inconditionnel, mais pourtant, je reste convaincu que la qualité et le cout sont très liés...

PS: Grillé par souviron, tout à fait d'accord avec lui!

[infofree]

Moi je dis plutôt que la différence sera au niveau de la qualité .....

Pourtant je précise bien que la différence est dans la QUALITE

[Logan Mauzaize]

Alors, je ne veux pas faire mon vieux con raciste, mais pourtant... J'ai bossé avec une équipe de R&D en Tunisie, et une en Inde. Ce sont les deux pires expériences de ma vie. Vraiment. J'ai l'impression qu'on va glisser sur un débat vers l'offshore, mais c'est bien de ça dont il est question.

D'expérience, les torts sont souvent partagés.

D'expérience, tu as un "grand esprit du management", qui n'a jamais vu un développeur de sa vie, qui compare comptablement deux solutions sur la seule base du cout: c'est pas cher, on engage, on fait!

La différence ici, c'est surtout l'industrialisation. Penser une fois, produit N fois. Genre "Write Once, Run Everywhere".

Et c'est répercuté jusqu'aux chefs de projets qui vont bosser, sans qu'on ne leur demande rien, en offshore. Ou avec des développeurs mauvais mais pas chers. Et, comme d'habitude, ce sera au chef de projet de serrer les dents, de faire avec, de satisfaire ses clients. Mais lui / elle le sait bien que çà va être plus dur, moins bon, et que les clients vont râler. D'expérience, toujours, cette idée d'aller au moins cher, ça dure quelques années, et puis, devant la merde que devient le logiciel, on arrête les frais et on relocalise.

En fait, vraiment rien de spécifique à l'Off-Shore. Le seul problème c'est que la dernière phrase n'est même pas vrai ... Le client se dit jamais qu'il va faire machine arrière, bien au contraire. Il va te demander pourquoi chaque évolution coûte de plus en plus cher, prend de plus en plus de temps et est livrée avec de plus en plus de bugs ...

Le souci c'est que quand tu as investi beaucoup d'argent, c'est difficile de revenir en arrière, voir de repartir de zéro. Surtout que pour avoir connu quelques projets de migration, c'est parfois pire qu'avant (au moins pendant une longue période de transition).

[rmaker]

Le seul problème c'est que la dernière phrase n'est même pas vrai ...

Cher Nemek, tu es en train de m'accuser de menteur sur ma propre expérience, et çà, c'est mal! Les faits restent indiscutables. Et j'ai précisé que çà relevait de ma propre expérience.

Allez, on reste potes et je réponds à la suite de ton post

Le client se dit jamais qu'il va faire machine arrière, bien au contraire. Il va te demander pourquoi chaque évolution coûte de plus en plus cher, prend de plus en plus de temps et est livrée avec de plus en plus de bugs ...

Cà dépend de la proximité du client, et bien sûr, du client lui même. Dans une problématique de qualité, j'ai constaté (mon expérience, toujours, hein, pas taper) un retour arrière, qui a beaucoup couté sur les premières années, mais qui était indispensable ne serait ce que pour garder le logiciel viable. Pas de bonne qualité, juste viable.

Le souci c'est que quand tu as investi beaucoup d'argent, c'est difficile de revenir en arrière, voir de repartir de zéro. Surtout que pour avoir connu quelques projets de migration, c'est parfois pire qu'avant (au moins pendant une longue période de transition).

Là dessus, je suis tout à fait d'accord avec toi, d'autant plus qu'il est facile de blamer les équipes pas offshorées, en leur disant qu'il fallait "mieux spécifier", "mieux suivre" les équipes offshore.

[Logan Mauzaize]

Cher Nemek, tu es en train de m'accuser de menteur sur ma propre expérience, et çà, c'est mal! Les faits restent indiscutables. Et j'ai précisé que çà relevait de ma propre expérience.

Oulà, loin de moi cette idée. Ce que je pense c'est qu'en général, le client (si c'est lui qui a imposé l'Off-Shore) ne songes même pas à revenir en arrière.

Allez, on reste potes et je réponds à la suite de ton post

C'est toujours avec plaisir, même si j'ai délaissé la taverne

Cà dépend de la proximité du client, et bien sûr, du client lui même. Dans une problématique de qualité, j'ai constaté (mon expérience, toujours, hein, pas taper) un retour arrière, qui a beaucoup couté sur les premières années, mais qui était indispensable ne serait ce que pour garder le logiciel viable. Pas de bonne qualité, juste viable.

Du coup la question qu'on peut se poser c'est, est-ce que si ce coût de retour en arrière avait été investi dans la mise en place, les choses n'auraient pas été meilleures ?

Bon je crois que tu as gagné, nous avons bien viré dans la discussion sur l'Off-Shore...


Pour en revenir au sujet, la multiplication des librairies n'est pas un mal en soi. Ce qui est mauvais c'est l’absence de maîtrise sur ces produits et sur leur nécessité.

[rimram31]

...Ou avec des développeurs mauvais mais pas chers...

Ce type de raisonnement me gène quelque peu ... surtout quand ça tourne autour de l'offshore. L'offshore n'échoue pas de la qualité des développeurs, j'ai même d'expérience rencontré parmi les gens les plus brillants de ma carrière a l'étranger. Mais malheureusement certains de ces projets sont torpillés dès le départ car pilotés uniquement par le coût et non les résultats, sans parler des difficultés inhérentes a un projet déporté bien entendu.

Pour faire un parallèle avec le hw, il est par exemple tout a fait possible de faire de l'excellente qualité en Chine mais jamais personne ne le leur a demandé, on leur a uniquement demandé de faire a un prix donné.

[Logan Mauzaize]

De mon expérience, sans que ce soit la catastrophe, il y a tout de même un écart de niveau. Cependant je reconnais suivre de beaucoup moins près les équipes locales.

Il y a deux problèmes que j'ai constaté.
Le premier c'est qu'ils ont la mentalité "servile". Et bien que nous ayons maintes fois précisé qu'ils n'étaient pas "fournisseur" mais "partenaire", ils se sont toujours mis dans cette position. Et on perd énormément de l'avantage à jouer "gagnant-gagnant" (ou "perdant-perdant"). Il en résulte qu'ils n'osent pas te déranger, se mettre à faire des horaires de folies (nuits blanches, viennent travailler les jours de congé et férié, etc.) avec l'effet contraire, parfois te cachent des choses, etc.

Deuxième point, on est trop confiant même quand on croit ne pas l'être. Gérer une équipe à distance, c'est très différent qu'en locale. Et même en prenant maintes précautions, il y a énormément de détails qui différent.

S'il y a un conseil que je donnerai à quelqu'un qui se lance dans l'Off-Shore, c'est de commencer en locale en faisant venir au moins 2-4 (voir plus en fonction de la taille des projets). Démarrer en travaillant par pair (un ordi pour deux), pendant un premier temps (ex: une semaine entière, puis 1j/2). Ensuite isoler complètement les deux équipes (mais en continuant à mutualiser les ressources). Enfin monter un environnement local propre à l'équipe Off-Shore et quelqu'un fasse de même là bas ; et valider que ca fonctionne avant qu'ils repartent.

[souviron34]

..
snip
..

Mais tout ceci est valable également dans toute GROSSE équipe...

Le problème n'est pas l'offshore et la qualité ou non des gens, mais la gestion... (communication, documentation, et bien-être ou mal-être des individus ou des équipes font partie de la gestion)

Pourquoi y a -t-il eu le Manifeste Agile et les diverses méthodologies (auquelles je n'adhère pas) ???

Parce que le modèle général utilisé était le cycle en V, avec des équipes énormes, et que ça ne marche pas....

Et là, on refait exactement la même chose...

Faut pas s'étonner d'obtenir les mêmes résultats...

Gérer de nombreuses équipes et personnes ralentit le projet, diminue la qualité, et coûte dans le fond énormément plus cher...

Mais malheureusement c'est le modèle utilsé le plus couramment.... Surtout dans les pays comme la France, où les acteurs sont de très grosses boites, soit SSII soit équivalents..

[rimram31]

... Le premier c'est qu'ils ont la mentalité "servile"...
...Gérer une équipe à distance, c'est très différent qu'en locale...

Sur le premier point, c'est je dirais "structurel" car le donneur d'ordre ne demande pas de prise d'initiative :-) (vécu, on le critique même!), et de fait "pisser du code" sans responsabilisation créé (presque) les mêmes problèmes que l'équipe soit dans le bureau d’à coté ou a des milliers de km de distance. On peut par contre se mettre d'accord sur une spécificité française de la prise d'initiative (qui n'est pas toujours bénéfique ...).

Sur le deuxième point, je te rejoins, plus que trop confiant, je dirais presque ignorant car on a jamais évalué objectivement les "non écrits" quand un projet est géré localement, pour faire simple: ce qui se dit "à la machine a café" et on va bâtir un projet externalisé avec des standards a peine adapté par rapport a un projet interne, échec assuré.

Mais a mon avis, le débat peut s'étendre a la gestion d'un projet informatique tout court, j'ai connu les mêmes difficultés simplement en lotissant un projet auprès d'un fournisseur de type SSII en ayant fait l'erreur de croire que leur prestation se limitait a ma barre dans mon beau tableau Excel ou mon plan MSProject ... (ou plutôt en ayant sciemment fait l'autruche de ne pas m'avouer la vérité!)

[Logan Mauzaize]

Sur le premier point, c'est je dirais "structurel" car le donneur d'ordre ne demande pas de prise d'initiative :-) (vécu, on le critique même!), et de fait "pisser du code" sans responsabilisation créé (presque) les mêmes problèmes que l'équipe soit dans le bureau d’à coté ou a des milliers de km de distance. On peut par contre se mettre d'accord sur une spécificité française de la prise d'initiative (qui n'est pas toujours bénéfique ...).

En fait c'est bien le contraire qui s'est passé. Nous leur avons laissé trop de liberté et ils se sont sentis perdus et n'ont pas osé demander. Et pire nous cachait qu'ils pataugeaient. Et finalement, on a fini par comprendre qu'ils nous faisaient pas confiance en tant que "partenaire" et nous traitaient comme des "commanditaires".

Sur le deuxième point, je te rejoins, plus que trop confiant, je dirais presque ignorant car on a jamais évalué objectivement les "non écrits" quand un projet est géré localement, pour faire simple: ce qui se dit "à la machine a café" et on va bâtir un projet externalisé avec des standards a peine adapté par rapport a un projet interne, échec assuré.

Tout à fait exact. Mais il ne faut pas non plus sous-estimer l'infrastructure (matériels, méthodes, etc.). On ne se rend pas compte des années passées à la batir et que ca ne se "transfert"/"copie" pas en quelques semaines ou mois. Surtout quand le reste suit son cours à côté.

Mais a mon avis, le débat peut s'étendre a la gestion d'un projet informatique tout court, j'ai connu les mêmes difficultés simplement en lotissant un projet auprès d'un fournisseur de type SSII en ayant fait l'erreur de croire que leur prestation se limitait a ma barre dans mon beau tableau Excel ou mon plan MSProject ... (ou plutôt en ayant sciemment fait l'autruche de ne pas m'avouer la vérité!)

Comme je le disais

En fait, vraiment rien de spécifique à l'Off-Shore.

C'est un problème de l'outsourcing ou même plus générale :

Mais tout ceci est valable également dans toute GROSSE équipe...

Ceci dit l'Off-Shore a de particulier, le choc des cultures et la particularité des entreprises qui sont sur ce marché. Tout comme peuvent l'être les SSII du point de vue d'un compte.

Concernant l' "agilité" qui je suis convaincu que c'est un remède aux méthodes que je cotoie actuellement. Et je me pense que certains de mes supérieurs le pensent également. Le problème c'est que le client qui ne veut pas s'engager dans cette voie.
A titre d'exemple, ils se dise suivre "RUP". Cependant les itérations sont quasiment aussi grosse que pour un nouveau produit.

Le souci c'est que quand tu as investi beaucoup d'argent, c'est difficile de revenir en arrière, voir de repartir de zéro. Surtout que pour avoir connu quelques projets de migration, c'est parfois pire qu'avant (au moins pendant une longue période de transition).

Intéressant de noter que ce point est aborder dans le même chapitre que l'extrait à l'origine de la discussion sous l'intitulé "L'utopie de la grande reprise à zéro".
Je résume :
"L'équipe souffre de la maintenance d'un code qui a mal vieilli. Sous la demande l'équipe et la chute de la productivité, la direction accepte la création d'une nouvelle version à partir de zéro.
Pour des raisons évidentes, les deux versions sont développées en parallèle. Le temps que la nouvelle version assure les mêmes fonctionnalités. Bien entendu les fonctionnalités se rajoutent et la nouvelle version doit suivre également.
La course dure plusieurs années (l'auteur donne l'exemple de 10ans). Au bout de ce laps de temps, les membres originels de la nouvelle version sont tous partis. Et l'équipe en place réclame, à son tour, un nouveau système car le dernier est mal concu."

[el_slapper]

(.../...)Intéressant de noter que ce point est aborder dans le même chapitre que l'extrait à l'origine de la discussion sous l'intitulé "L'utopie de la grande reprise à zéro".
Je résume :
"L'équipe souffre de la maintenance d'un code qui a mal vieilli. Sous la demande l'équipe et la chute de la productivité, la direction accepte la création d'une nouvelle version à partir de zéro.
Pour des raisons évidentes, les deux versions sont développées en parallèle. Le temps que la nouvelle version assure les mêmes fonctionnalités. Bien entendu les fonctionnalités se rajoutent et la nouvelle version doit suivre également.
La course dure plusieurs années (l'auteur donne l'exemple de 10ans). Au bout de ce laps de temps, les membres originels de la nouvelle version sont tous partis. Et l'équipe en place réclame, à son tour, un nouveau système car le dernier est mal concu."

Un autre texte sur le sujet. Ma position n'est pas aussi tranchée, mais je considère quand même que mettre à la poubelle un code qui marche, c'et, euh, compliqué, pour rester poli. La seule fois ou on m'a demandé de le faire, j'ai construit une nouvelle structure, simple et propre, et j'y ai mis en place, petit à petit, des bouts de code qui fonctionnaient dans l'ancienne appli. J'en ai profité pour les refactoriser(en cherchant à garder une algorithmie identique). Il y en a même une majorité que j'ai compris en les refactorisant(d'autres pas. Je n'ai toujours pas compris comment était calculée la taxe d'assurance. Mais elle était identique dans les deux versions, et les experts métiers n'ont pas trouvé d'erreur).

Mais si ça a été un grand succès(technique et financier), c'est parceque j'avais les moyens de faire une comparaison TOTALE entre l'ancien et le nouveau système. C'était du batch, et je générais juste un fichier(en direction de l'impression) en lisant dans les référentiels. Sur une appli transactionelle, qui passe son temps à mettre à jour les référentiels, je pense que j'aurais dansé.

Enfin, je dois dire que je me coltine actuellement des programmes en COBOL généré. Exemple de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
A003-03-1.                                 
    IF  REG-CMP-REN (I-REGLE)    =    6    
    NEXT SENTENCE ELSE                     
    GO TO    A003-04-1.                    
    MOVE     'CC' TO   NAT-REG (I-NAT-REG).
    GO TO    A003-04-4.                    
A003-04-1.                                 
    IF  REG-CMP-REN (I-REGLE)    =    7    
    NEXT SENTENCE ELSE                     
    GO TO    A003-05-1.                    
    MOVE     'EC' TO   NAT-REG (I-NAT-REG).
    GO TO    A003-05-4.                    
A003-05-1.                                 
    IF  REG-CMP-REN (I-REGLE)    =    8    
    MOVE     'ED' TO   NAT-REG (I-NAT-REG).
A003-05-4.    EXIT.                        
A003-04-4.    EXIT.

La tentation est FORTE de tout mettre à la poubelle, et de tout recommencer. Même en BF ça serait plus lisible(je rigole, mais pas beaucoup).

Mais la tentation est mauvaise conseillère. Cette horreur marche. Si on veut la moderniser, il est préférable de réécrire petit bout par petit bout. Ici, ça donnerait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
A003-03-1.
    EVALUATE REG-CMP-REN (I-REGLE)
       WHEN 6      MOVE 'CC' TO   NAT-REG (I-NAT-REG)
       WHEN 7      MOVE 'EC' TO   NAT-REG (I-NAT-REG)
       WHEN 8      MOVE 'ED' TO   NAT-REG (I-NAT-REG)
       WHEN OTHER  CONTINUE
    END-EVALUATE
    .

C'est plus lisible, non?(même si ça reste du COBOL) Une fois qu'on a fait ça partout, on renomme les paragraphes et les variables, et on a TOUJOURS le même code, en beaucoup plus lisible. Ensuite, il arrive souvent qu'on trouve des choses mettables en commun, etc..... Et, à chaque étape, on reste iso-fonctionnalités. J'ai remplaçé 17 lignes de spaghettis dont 4 GO TO par un bête switch de 8 lignes. Je n'ai pris aucun risque. Ca marche toujours. Et c'est facile à vérifier par test unitaire.

[souviron34]

Intéressant de noter que ce point est aborder dans le même chapitre que l'extrait à l'origine de la discussion sous l'intitulé "L'utopie de la grande reprise à zéro".
Je résume :
"L'équipe souffre de la maintenance d'un code qui a mal vieilli. Sous la demande l'équipe et la chute de la productivité, la direction accepte la création d'une nouvelle version à partir de zéro.
Pour des raisons évidentes, les deux versions sont développées en parallèle. Le temps que la nouvelle version assure les mêmes fonctionnalités. Bien entendu les fonctionnalités se rajoutent et la nouvelle version doit suivre également.
La course dure plusieurs années (l'auteur donne l'exemple de 10ans). Au bout de ce laps de temps, les membres originels de la nouvelle version sont tous partis. Et l'équipe en place réclame, à son tour, un nouveau système car le dernier est mal concu."

Un autre texte sur le sujet. Ma position n'est pas aussi tranchée, mais je considère quand même que mettre à la poubelle un code qui marche, c'et, euh, compliqué, pour rester poli.

Je re-citerais un blog déjà cité par moi ailleurs :

Rewrites Considered Harmful?

En particulier sa conclusion :

A suggestion: If you have a very successful application, don't look at all that old, messy code as being "stale". Look at it as a living organism that can perhaps be healed, and can evolve. You can refactor, you can rewrite portions of the internals to work better, many things can be accomplished without abandoning all the experience and error correction that went into that codebase. When you rewrite you are abandoning history and condemning yourself to relive it.