Discussion :

[souviron34]

@SlashEne :

il est normal qu'en etant etudiant tu penses comme ca.


Ce qu'on essaye de te dire , c'est que la realite est toute autre... dans tous les cas de figure... Que ce soit dans des entreprises 100% informatique, ou des societes de service, ou des services infos, etc etc...

L'ideal c'est....... un ideal....

La realite, que ce soit a cause de la technique, du temps, du budget, etc etc, est limitee...

Sans compter la compatibilite, la maintenance, la formation....

Je peux te dire qu'en 25 ans de carriere, je n'ai pas vu une seule fois un code vraiment propre.........

Et pourtant, que ce soit dans des petites boites, des multi-nationales, des boites a 100 000 euros ou a 100 millions d'euros de chiffre d'affaire....

[SlashEne]

c'est dur à entendre tout ça
que quelqu'un qui connait quelqu'un qui applique mes idéaux se montre
je ne veux plus avoir à toucher du code pourri moi

[zaventem]

je ne veux plus avoir à toucher du code pourri moi

Attention, si nous essayons de t'avertir sur les réalités du terrain, n'imagine pas que tout est forcément noir. Je crois que chacun ici tente de faire le code le plus propre et le mieux conçu possible et qu'en général il y parvient.

Simplement, il arrive parfois que des contraintes extérieures au domaine informatique nous forcent à malmener les règles de bonnes pratiques.

Et puis, comme j'ai coutume de dire :"un code pourri est un code que j'aurais écrit autrement", donc oui, tu aura encore à toucher du code qui sent pas bon!

[Alpha31]

Ce qui ressort de la discussion, c'est que finalement tout le monde est a peut prés d'accord avec tout le monde.

La seul chose qui change ce sont d'un coté "Les résignés", et de l'autre "Les idéalistes".

Moi je pars du principe qu'il est préférable de rester dans l'optique de "l'idéaliste".
Car les autres réalises les choses par "peur" et "contrainte" et non par "espoir" et "passion".

Je vois que chacun parle plus ou moins d'un cas auquel il a été confronté, donc l'ont pourrait certainement discuter sur chacun des cas et cela indéfiniment.

Néanmoins pour résumé un projet de soft ou de site de manière hypra simple, l'on a :

C - Le Client / Le Demandeur
E - L'entreprise / Le Fournisseur
R - Les Réalisateurs / L'équipe du projet
P - Le Projet / Site / soft / etc

Je pars du principe que quelque soit le cas :

Quand C demande a E le besoin P dans un Temps T,
Alors E conculte R a propos de P et de T

R ne doit pas dire NON (*cas de la tutelle),
R doit savoir dire :

Nous pouvons faire P pour C, mais pas dans le temps T.
Nous pouvons faire P pour C dans le temps (T + x) ou partiellement pour le temps T

Point Barre !!!

Ce n'est en aucun cas a C d'estimer le temps de la réalisation de P.
Car C n'y connait strictement rien en termes de réalisation de P

Je parlerais presque d'impolitesse, (un client se doit-il, être impolit ?), je ne le pense pas !!!

Si C n'est pas content de T, alors c'est lui qui à tort !!!

- Soit il fallait qu'il demande P plus tôt qu'il ne l'a fait (C a tort)
- Soit ce n'est pas faisable et il doit l'accepter, donc il n'a même pas à être mécontant !!! (C a encore tort)

----
Alors effectivement, il y a une belle faille voir 2.

- La première :
R s'en fout de faire du Travaille de Merde et il dit toujours Oui a C

- La deuxième :
C dit a E alors, je vais allez voir a coté si une autre boite peut pas me faire P en T.
Boite qui pourra dire oui a C pour T car elle fait du travaille de merde.

- C'est peut être à cette 2ièm qu'il faut finalement trouvé une solution, non ?

- Des idées ?









A demande

[SlashEne]

- La deuxième :
C dit a E alors, je vais allez voir a coté si une autre boite peut pas me faire P en T.
Boite qui pourra dire oui a C pour T car elle fait du travaille de merde.

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

Idéalement une solution alternative serait de dire : "je ne peux pas respecter toutes vos spécification en pour T" cependant je peux vous livrer une version du produit tout les T/n, comme cela vous pourrez voir l'évolution du produit par vous même, le tester et nous donner un feedback.
Lorsque le produit vous plaira vous pourrez abandonner le projet à tout moment et nous payer juste pour le travaille effectué.
Si vous souhaitez des amélioration nous continuerons de travailler pour.

C'est le principe des méthodes agiles et je ne vois pas l'inconveniant ni pour l'équipe de dev, ni pour le client.

Qu'en pensez vous ??

[mourbare]

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

[el_slapper]

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).

Le truc, c'est que le système informatique n'a pas été conçu d'une traite. Donc on a un libellé client qui apparait sur un courrier(y'en a qui avaient flairé le coup); il faut donc :
_retailler la base de données(ça, c'est pas le plus dur)
_identifier et recompiler l'ensemble des programmes qui se trimballent ce libellé(ça se compte par milliers)
_identifier et redessiner tous les écrans transactionnels ou ce libellé apparait(et parfois il faut pousser d'autres données pour faire de la place; à chaque fois, il faut poser la question aux concepteurs de savoir ce qu'on pousse)
_identifier et redessiner toutes les maquettes courrier

etc.....

(.../...)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.

la POO? Je bosse en COBOL. je n'ai pas accès à des objets. Je n'ai même pas accès à des fonctions. Je dois faire sans. Et même quand tu en as, ils ne sont pas forcéments pensés pour l'évolution à laquelle tu vas être confronté.

(.../...)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.

ça, c'est l'effet d'expérience. Seulement, tout le monde n'acquiert pas l'expérience à la même vitesse. Si certains sont capables de beaucoup, d'autres seront incapables de bouger d'une méthode à l'autre. J'ai vu une DP diriger un projet JAVA/JEE comme si c'était du Cobol. Le choc culturel avec les Javaïstes a été total. Elle n'a jamais compris pourquoi les développeurs avaient besoin d'un accès internet. Forcément, en Cobol, y'a pas d'API, on fait tout à la main.....donc elle a traité les devs d'incompétents(sans doute la meilleure équipe que j'ai jamais vue, pourtant).

(.../...)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 ?

mais si la plupart des clients n'en veulent pas? Si tu mets toutes les options disponibles à tout le monde, tu augmentes fortement les difficultés d'administration de ton logiciel; plus de couts d'administration ==> moins d'interêt à acheter le logiciel ==> moins de clients.....

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

Idéalement une solution alternative serait de dire : "je ne peux pas respecter toutes vos spécification en pour T" cependant je peux vous livrer une version du produit tout les T/n, comme cela vous pourrez voir l'évolution du produit par vous même, le tester et nous donner un feedback.
Lorsque le produit vous plaira vous pourrez abandonner le projet à tout moment et nous payer juste pour le travaille effectué.
Si vous souhaitez des amélioration nous continuerons de travailler pour.

C'est le principe des méthodes agiles et je ne vois pas l'inconvenient ni pour l'équipe de dev, ni pour le client.

sauf que ce discours est inacceptable pour le client; il demande un produit, il veut le produit; il a autre chose à faire que de se plier aux désidératas méthodologiques de son fournisseur. Il paye, il a besoin du produit pour lequel il a payé.

[zaventem]

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

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

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

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

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

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

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

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

[SlashEne]

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

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

[ac_wingless]

Quelques exemples de projets:
- refondre 43000 lignes de Fortran, dont une partie en Fortran II. Tous les auteurs sont à la retraite ... voire un peu plus loin encore.
- passer 21 Gbit/s entre un périphérique de PC et un autre (21 Gbits/s, c'est beaucoup beaucoup beaucoup, surtout quand on n'a pas accès au firmware d'un des périphériques en question)
- faire tourner sur Vista un programme mi-assembleur mi-C écrit en 1986 utilisant un bus ISA.
- etc. peu importe.

Ce que ça montre, c'est qu'un projet est parfois très contraint par le passé, ou par les autres partenaires. Bien sûr, j'ai aussi assez souvent des programmes tout propres à démarrer avec un choix total, et là on s'éclate avec Boost et Qt et ça fait du bien. Mais dans la vraie vie, il faut bien s'occuper des deux. Or, il est impossible d'appliquer de la POO à du Fortran II, des machines virtuelles à 21 Gb/s, des diagrammes UML pour simuler des timings fins de matériel qui n'existe plus.
Quant à dire "ah ben c'est un parfait exemple, si seulement les programmeurs avaient été propres dès le départ, ben la maintenance serait plus simple par la suite", c'est ignorer que ces programmes ont été réalisés avec les outils et les contraintes de l'époque, dans les règles de l'art de l'époque. Après 20 ou 30 ans de métier, vous verrez d'un autre œil les méthodes agiles, technologies .net et autres outils RAD. Çà, c'est juste l'écume du moment, ce sera regardé dans 30 ans comme on considère maintenant les conventions de notations MS pour Win32, les /common/ du Fortran et autres macro assembleurs des années 80 (je plains les très jeunes qui vont se cogner les milliards de tonnes de HTML/Ajax/ASP pourri que les jeunes pondent "agilement" en ce moment - chacun sa croix, nous on s'est cogné cogné les relents de MS-DOS - dans le genre pas propre, c'est costaud aussi, et pourtant, à l'époque je suis sûr que tout le monde faisait de son mieux).

Enfin, pour ce qui est d'écrire du "code propre", il y a deux problèmes dans l'expression:
- premièrement, c'est tout relatif. Le code propre d'un autre ne parait pas toujours propre, et vice-versa. Je passe mes Vendredis après 18h à regarder les check-ins, et je dois reconnaitre que certains collègues dont je trouve qu'ils font du code sale sont en toute objectivité très performants, y compris en maintenance et fiabilité. De même, son propre code parait moins propre après un certain temps, surtout en début de carrière... A mon grand age, je ne progresse certainement plus, et en plus je code de moins en moins, donc mon code d'il y a 5-10 ans me parait presque trop fort pour moi
- et surtout, par définition de "faire un effort pour coder mieux", cela prend plus de temps (si on parle de faire du code meilleur en moins de temps et d'effort, c'est un problème de méthode, voire carrément de faute professionnelle). Comme tout investissement, il doit être jugé sur ce que cela rapporte, voire sur ce que cela rapporte de plus que si ça avait été investi autrement. Et là, tous les arguments cités en faveur de faire du code propre doivent bien sûr être pris en compte: cela fera des programmeurs plus passionnés, du code plus fiable, des produits plus faciles à maintenir, etc. En soi, c'est Bien. Par contre, passer du temps à le faire, ou déclencher des conflits interne à l'équipe sur ce qui est "propre", c'est Mal. Le Bien doit toujours l'emporter sur le Mal (sinon, où va-t-on ma bonne dame?). Cela n'a rien à voir avec se résigner ou être idéaliste, c'est tout simplement du pragmatisme ras-des-pâquerettes.

[zaventem]

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

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

[SlashEne]

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

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

J'ai compris ce que tu soulignes mais

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

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

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

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

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

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

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

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

[_vince_]

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

La plupart ne le font pas expres

[zaventem]

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

Mais le monde réel n'est pas ton monde idéal. Le client lui exige d'avoir une date à laquelle il aura son outil opérationnel.

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

Point de vue financier, ça ne change rien. Tu paies tes devs et cela ne te rapportera rien.
De plus, toutes les personnes ne sont pas interchangeables facilement. Quand je regarde autour de moi, là maintenant:
1 expert datawarehouse,
1 dev crystal report
2 dba oracle,
1 dba sql serveur,
3 dev forms oracle
2 dev c#
...

Crois tu vraiment que l'on puisse transférer ce type de profils aussi différents d'un projet à l'autre sans cout exorbitant?

[el_slapper]

(.../...)De plus, toutes les personnes ne sont pas interchangeables facilement. Quand je regarde autour de moi, là maintenant:
1 expert datawarehouse,
1 dev crystal report
2 dba oracle,
1 dba sql serveur,
3 dev forms oracle
2 dev c#
...

Crois tu vraiment que l'on puisse transférer ce type de profils aussi différents d'un projet à l'autre sans cout exorbitant?

Et même si ils ont la technique. La connaissance fonctionelle est un plus énorme. J'ai plus de 4 ans de COBOL derrièrre moi, plus quelques autres trucs. Sur les applications que je connaissais, je me balladais. Là, je débarque en assurances, et je dois tout réapprendre. C'est quoi un numéro de police? Pourquoi des fois c'est sur 8 et pas sur 11? Ou on trouve la définition des données? Pourquoi mon programme y compile pas? Comment on fait, dans l'appli, pour créer un client? C'est quoi le code produit d'une automobile? d'un bateau de plaisance? d'un chasseur?

en bref, au bout de 4 mois, je suis encore loin d'être au point - alors même que je suis confirmé sur les techs utilisées.....Dans 2 ans, ça ira beaucoup mieux.

[SlashEne]

quand j'ai parlé des binome qui change toute les iterations, je me suis trompé c'est en effet pas entre projet mais au sein d'un même projet et d'une meme équipe.

Donc oui... je ne vois comme empêcher ce problème.

Dans une entreprise qui agit "normalement" que se passe t'il lorsque il n'y a pas assez de personne pour remplir la demande d'un client ?
Et que se passe t'il entre le moment ou un projet fini, et le moment ou un autre commence ?
Comment fait-elle pour éviter les "blanc" pendant cette période ?
Que se passe t'il quand il n'y a plus de projet pour un dev forms oracle par exemple ?

Vous me donnez l'impression qu'il n'y a pas de solution qui permette de concilier le client, le code propre et la compétitivité.

[souviron34]

Dans une entreprise qui agit "normalement" que se passe t'il lorsque il n'y a pas assez de personne pour remplir la demande d'un client ?

On embauche si le delai est long, sinon on fait du sur-temps (semaines de 40, 50, 60, 80 heures).

Et que se passe t'il entre le moment ou un projet fini, et le moment ou un autre commence ?
Comment fait-elle pour éviter les "blanc" pendant cette période ?

A part dans les SSII, tres tres rare.. En general, l'autre a commence quand le premier est pas fini...

[zaventem]

Dans une entreprise qui agit "normalement" que se passe t'il lorsque il n'y a pas assez de personne pour remplir la demande d'un client ?

Et bien en général, on commence par s'arranger avec le demandeur pour éviter ces situations et on établit des priorités entre les projets. Quand ce n'est pas possible, comme l'a dit souviron34, on engage, on fait des heures sups, on tente de trouver des compromis,... On s'adapte quoi.

Et que se passe t'il entre le moment ou un projet fini, et le moment ou un autre commence ?
Comment fait-elle pour éviter les "blanc" pendant cette période ?

Un quoi? En général - je parle pour ceux qui bossent en internes, je ne connais pas assez les SSII pour parler de leur cas - t'as pas de blanc, ou de très petits. Dans mon cas, on a un planning des grands projets fait jusque 2012 sans trou pour chacun de l'équipe. Et a peu près autant de temps de dev de "petits" projets à intercaler entre. Un des plus grands blanc que j'ai eu c'est aujourd'hui: une journée entre la fin de la mise en production de mon dernier projet et le début de mes vacances, y avait rien que je puisse boucler en une journée.

Que se passe t'il quand il n'y a plus de projet pour un dev forms oracle par exemple ?

Puisque c'est moi qui ait cité l'exemple, j'y répondrai. Comme je l'ai dit, on a toujours des projets en attente. Dans ce cas-ci, puisqu'on abandonnera cette techno d'ici deux ans, ils se forment peu à peu au C# et oui, pendant un bout de temps ils feront du vilain code et non, les dev plus confirmés ne pourront pas passer derrière eux à chaque ligne écrite.

Vous me donnez l'impression qu'il n'y a pas de solution qui permette de concilier le client, le code propre et la compétitivité.

La solution n'existe pas. Il existe cependant des solutions qui donnent chacune de plus où moins bon résultats suivants les situations mais elles nécessitent toujours de prendre du recul par rapport aux méthodes toutes faites. Elles ont cependant toutes à ma connaissance un point commun: le bon sens.

[GrandFather]

Vous me donnez l'impression qu'il n'y a pas de solution qui permette de concilier le client, le code propre et la compétitivité.

S'il existait une solution universelle pour concilier tous ces facteurs, pour un développement respectant toutes les règles de l'art et satisfaisant toutes les parties, on n'aurait pas actuellement environ un projet abandonné avant terme sur trois et des dépassements de budget de 100% pour la moitié d'entre eux... Le développement reste globalement, malgré les progrès de ces dernières années en ingénierie logicielle et qui vont dans le sens de l'industrialisation, une activité quasi-artisanale, difficile et sujette aux risques.

En ce qui concerne la différence entre être informaticien dans une SSII ou dans le service informatique d'une entreprise dont ce n'est pas le coeur de métier, selon mon expérience et pour avoir occupé les deux postes, je dois dire que ma préférence va largement au second cas de figure, pour ce qui est de la possibilité de travailler "proprement".

J'ai commencé ma carrière en SSII, où j'ai appris la réactivité et l'adaptation (parfois aux frais du client ), mais où pour respecter des deadlines critiques (sinon pas de salaire à la fin du mois) j'ai parfois dû pondre des trucs dont je ne suis pas spécialement fier...

Depuis que je travaille dans le service informatique d'une grosse boite, et que je ne suis plus soumis à la pression commerciale, il m'est bien plus loisible de respecter (et de promouvoir auprès de mon équipe) les "best practices", de soigner l'architecture et la conception, etc. Par contre, cette position enseigne l'humilité : mon service de développement est rattaché à une Direction des Ressources Logistiques, ce qui signifie que dans l'esprit de nos décideurs nous avons la même importance stratégique que les chauffeurs ou les électriciens de l'entreprise... (avec heureusement pour nous une moyenne de salaire bien plus importante). 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.

Pour moi, il n'existe pas de situation idéale, on passe notre temps à jongler entre des contraintes antagonistes, et même ceux dotés de conscience professionnelle en sont souvent réduits à faire de leur mieux en fonction des circonstances.

[BugFactory]

J'ai vu personnellement une application tellement pourrie que les coûts de maintenance en étaient multipliés par 4. Et quand je dis par 4, ce n'est pas par rapport à un projet "idéal" mais par rapport à des projets "ordinairement crades". Je mettais 4 fois plus de temps que je n'aurais dû à faire quoi que ce soit. On était 16, mais 4 personnes auraient dû suffire pour ce projet. Sans parler du nombre de retours de bogues.

Quand j'ai vu leur monstre, j'ai été voir le chef de projet pour lui dire que l'application avait besoin d'une réécriture complète. Il m'a répondu que c'est ce que tout le monde disait, mais que le client n'en voyait pas l'intérêt. J'ai suggéré que l'on fasse cela en interne, en arguant que les économies réalisées couvriraient largement nos coûts de développement. Peine perdue.

J'ai compris depuis que la boîte préférait facturer 16 personnes que 4.

Seulement, le client, pas si bête, a fait établir des devis par d'autres SSII. Résultat : on a perdu un contrat que l'on avait depuis des années.

Si nos commerciaux / chefs de projet avaient eu le courage de dire au client qu'il se tirait une balle dans le pied, on n'aurait plus que 4 personnes sur ce projet. Au lieu de ça, ils lui ont dit "Allez-y, ça fait pas mal!", et on n'a plus personne du tout.

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.