Discussion :

[e-ric]

Personnellement, je préfère des tâches de plus en plus valorisantes qui se rapprochent de l'architecture de l'Entreprise/SI, l'intégration des systèmes d'informations, middlewares, l'urbanisme et qui permettent de monter en compétence dans ce sens. C'est la vocation de chaque développeur de se spécialiser dans l'architecture, l'urbanisme, le métier et l'analyse fonctionnelle, le management de projet, l'audit, ou carrément sortir du domaine informatique vers un autre domaine dont il est passionné.

Tu ne serais consultant chez IBM, des fois ? C'est tout à fait la façon de penser de ces grosses boîtes. Ca en fait des choses si tu arrives à tout faire avec une seule tête. C'est une leçon apprises par coeur ?

[e-ric]

Qu'est ce que j'en ai a carré de ton urbanisme fonctionnelle d'analyse de projet audité !!!!!!!!!!!!!!!

C'est un peu le fond de ma pensée. La mode est aux grands mots mais les résultats ne sont pas toujours là. Tant que les petits en bas de l'échelle mettent de l'huile dans les rouages, tout va bien pour les plans de carrières de nos élites éclairées...

[e-ric]

Là, par contre, d'accord. "Vous êtes l'élite de la nation", c'est une foutaise gravissime. Le pire, c'est que les profs y croient vraiment(en tout cas, on a eu la preuve que les notres y croyaient vraiment).

Il n'y croient peut-être pas mais c'est la combine et ... leur gagne-pain. Les frais de scolarité sont à la hauteur des bobards qu'ils sortent à leurs ouailles.

[Caro999]

Ah, maintenant on parle le même vocabulaire. J'ai eu une formation PMI de 5 jours en Avril dernier. Le formateur a glissé, entre deux process, la phrase suivante : "Le PMI s'est penché sur le cas des développements agiles. Pour l'instant, ils ne sont pas parvenus à les gérer". Et c'est normal.

PMI, c'est bien pour les projets linéaires : on sait ou on est, on sait ou on va, et on découpe le chemin de l'un vers l'autre. Ca n'est pas forcément facile. Exemples de projets linéaires : le viaduc de Millau, les normes bancaires Bâle2/Bâle3. Pas des faciles, hein, mais

Seulement, une majorité des problèmes informatiques sont tordus. Exemples de projets tordus : améliorer un modèle de voiture, mettre en place un logiciel de gestion.

Un problème tordu, pour ceux qui ont la flemme de lire l'article(c'est un tort), c'est un problème qui :
(1)n'a pas de formulation définitive
(2)n'a pas de top simple qui permette de savoir qu'on a fini
(3)a pour solution non pas du vrai-faux mais du bon-mauvais
(4)n'a ni test immédiat ni de test ultime
(5)toute solution a des conséquences, souvent irréversibles
(6)n'a pas de liste complète de solutions
(7)est essentiellement unique
(8)peut être considéré comme le symptôme d'autres problèmes
(9)a des causes qu'on peut expliquer de nombreuses manières différentes
(10)le planificateur n'a pas le droit à l'erreur

Les principales méthodes efficaces pour gérer un problème tordu sont de :
(1)reconnaitre que c'est un problème tordu
(2)le découper en plus petits éléments, pas forcément linéaires, mais au moins moins tordus(on notera que cette approche n'a aucun sens sur un problème linéaire : le viaduc de Millau relie, ou ne relie pas, les deux plateaux entourant la vallée; faire déjà un pilier pour voir, et pour l'exploiter, ça n'a pas de sens). Les éléments plus petits, idéalement, apportent chacun un plus fonctionnel, et peuvent être livrés séparément.
(3)appliquer une démarche adaptative pour les morceaux tordus insécables. Ca veut dire qu'on commence avec une feuille de route qui donne des principes généraux, on fait un prototype, on se donne les moyens de le changer drastiquement, et très régulièrement, les parties prenantes donnent leur avis. On le prend en compte, et on recommence. SCRUM marche à peu près comme ça(en plus formalisé).

Mon expérience personelle, c'est que 10% des projets importants sur lesquels j'ai bossé étaient linéaires(dont les deux actuels : une refonte purement technique, et un changement reglementaire - avant, je devait plutôt en être à 5%). Pour eux, le PMI et sa référence le PMBOK seront difficille à surpasser en termes d'efficacité.

Mais pour les autres 90%, c'est juste une catastrophe. A chaque fois qu'une MOA a essayé de décrire complètement toutes les fonctionnalités dont elle aurait besoin, ça a été une catastrophe. Tout simplement parceque c'est jouer aux devinettes. Ca ne rentre pas dans un cerveau humain. Donc, on met plein de trucs qui ne serviront jamais, et on oublie un tas de trucs qui seraient tellement utiles, et on fait un seul énorme projet qui sortira dans 5 ans, et on gèle dès le début une ergonomie qui est plus que foutraque.....

Un problème tordu, ça se comprend au fur et à mesure qu'on le résoud. D'ou l'aberration d'une méthode waterfall genre PMI pour le résoudre.

Mais tu as raison sur un point : tout le monde s'y met. C'est une catastrophe, qui est liée aux autres problèmes évoqués dans ce fil : on ne fait pas confiance au programmeur. Toyota fait confiance à chacun de ses ouvriers, et compte sur chacun d'entre eux pour améliorer le fonctionnement de l'usine. Toyota n'écrit pas un manuel long de 50 pages pour chaque poste de travail. Toyota exige des gens du terrain qu'ils réécrivent le manuel à leur sauce régulièrement - et que celui-ci ne contienne que le strict minimum. Ca ne leur a pas trop porté malheur.

Ce qui nécéssite :
(1)je fais confiance à tout le monde
(2)j'ai les moyens de vérifier la qualité à chaque poste
(3)je ne me sert pas de ces informations chiffrées pour juger les gens(i.e. pas de prime d'objectif individuel : l'ouvrier a une prime à la performance de l'usine, le directeur à une prime à la performance du groupe)

En d'autres termes, voir chaque maillon(humain) de la chaine comme un être pensant, intelligent, naturellement motivé à faire mieux, et le mieux à même de percevoir des défauts de la partie dont il a la responsabilité. Comme tu le soulignes, on en prend pas le chemin

C'est un procès d"intention. Tu parles de choses que tu ne connais pas.

Le PMI ça sert à professionaliser la pratique des chefs de projets.

Y'a pas de waterfall dans le PMI. Le PMI ça sert pour tous les types de projets, c'est à dire toutes les activités qui possèdent une dose certaines d'inconnu et qui requièrent un processus d'élaboration progressive et je pèse mes mots.

Et il n'y a pas de méfiance à l'égard des intervenants des projets. Il n'y a pas de flicage ou quoi que ce soit. Bien au contraire, le PMI étudie les relations entre parties prenantes et prône le respect, le partage d'info et la communication entre les membres des équipes, le team building, envisager la juste rétribution des équipes.

Tu me parles de Toyota. Le PMI reprend les grands principes des processus de qualité à la japonaise, Kaisen, l'amélioration continue, etc... Il explique les outils à disposition des Pm: Roue de Deming, le diagramme d'ishiwara, etc...

Tu crois vraiment qu'un truc qui fliquerait les intervenants genererait ce niveau d'adoption mondiale?

Allez, c'est pas la peine que je continue... Ca sert à rien.

[Graffito]

Au delà de la gestion de projet, coder occupe toujours une partie de mon temps et c'est pour moi toujours aussi gratifiant : il suffit que le code soit bien conçu et tourne bien pour mon bonheur. Je précise que les applications que nous devellopons ont un objectif plus scientifique ou technique qu'un aspect gestion;

Etant en fin de carrière, si je devais postuler pour un nouvel emploi, mes goûts me porteraient à accepter de réduire significativement mon salaire (jusqu'à -50%) pour être "simple" programmeur plutôt que chef de projet.

[el_slapper]

Il n'y croient peut-être pas mais c'est la combine et ... leur gagne-pain. Les frais de scolarité sont à la hauteur des bobards qu'ils sortent à leurs ouailles.

Si, si "vous êtes meilleurs que les autres", ils y croient. En tous cas, les notres y croyaient. L'un d'entre eux a frôlé la crise cardiaque le jour ou il a assisté à un entretien d'embauche, quand il s'est aperçu que les élèves de son école n'étaient pas meilleurs que ceux des autres écoles(pas pires non plus, hein, c'était du très bon niveau partout - mais pas sans faiblesses). En plus, c'était une école publique, donc les frais de scolarité.....

[Aqualys]

Je vais avoir l'air d'un vieux dinosaure... mais tant pis, j'avoue être toujours intéressé par le développement et le codage à presque 50 ans.

Évidemment, en plus de 2 décennies, tout à changé, ou presque , mais c'est aussi ce qui est motivant ; apprendre.

Je ne vais faire qu'une remarque de vieux , depuis quelques années je rencontre de plus en plus de jeunes développeurs, plein de morgue et pas encore sevrés, qui ne veulent plus prendre la peine de comprendre un existant ( toutes ces lignes de code écrites par le cerveau d'un has been, beurk ! ) mais tout réécrire.
Incompétence ou égo démesuré ?
Un seul dicton ( d'un directeur de projets ) : ' on ne touche pas à du code qui fonctionne '

[kdmbella]

Je ne vais faire qu'une remarque de vieux , depuis quelques années je rencontre de plus en plus de jeunes développeurs, plein de morgue et pas encore sevrés, qui ne veulent plus prendre la peine de comprendre un existant ( toutes ces lignes de code écrites par le cerveau d'un has been, beurk ! ) mais tout réécrire.
Incompétence ou égo démesuré ?
Un seul dicton ( d'un directeur de projets ) : ' on ne touche pas à du code qui fonctionne '

suis bien d'accord avec vous on pense pouvoir tout réécrire croyant
faire mieux ...ou simplement croyant que c'est plus facile de reprendre que de chercher à comprendre
D'autre part j'adhère a cette "maxime" : Pas touche à du code qui marche

[e-ric]

Je vais avoir l'air d'un vieux dinosaure... mais tant pis, j'avoue être toujours intéressé par le développement et le codage à presque 50 ans.

Évidemment, en plus de 2 décennies, tout à changé, ou presque , mais c'est aussi ce qui est motivant ; apprendre.

Je ne vais faire qu'une remarque de vieux , depuis quelques années je rencontre de plus en plus de jeunes développeurs, plein de morgue et pas encore sevrés, qui ne veulent plus prendre la peine de comprendre un existant ( toutes ces lignes de code écrites par le cerveau d'un has been, beurk ! ) mais tout réécrire.
Incompétence ou égo démesuré ?
Un seul dicton ( d'un directeur de projets ) : ' on ne touche pas à du code qui fonctionne '

je comprend le point de vue. Il est vrai que le besoin de réécriture n'est pas toujours impérieux mais cela arrive, l'accumulation de couches de modificaitons rend les programmes difficilement lisibles. Mais une réécriture a un coût important qui ne se limite pas à celui du codage, il faut tester, documenter, valider, encadrer ...

Ceci dit, je travaille depuis 2 ans en Cobol (mainframe) et le discours selon lequel il faut toujours tout réécrire n'a pas du tout le même impact qu'en micro-informatique, on est beaucoup mouins exhubérant, on va dire.

La maintenance n'a pas la cote, c'est pourtant l'essentiel du travail en
développement. Je dirai que c'est par la maintenance corrective qu'il faut commencer, à voir des conneries écrites par ses prédécesseurs, cela incite à coder correctement. enfin, je vois la chose comme ça. Je dois être un vieux dinosaure (pléonasme), pas grave, j'aime la paléontologie et les dinosaures.

[transgohan]

J'ai 25ans donc j'ai encore le temps de changer d'avis mais...
Je n'ai aucune volonté d'évoluer vers un poste de chef ou approchant.
Cela ne m'intéresse pas.
J'aime coder, par contre je n'aime pas pisser du code...

[Arnard]

heuuuu, je suis le seul à mettre mes outils à jour tous les 1, 2 ans pour être au fait des technos, à me former constamment aux nouvelles technos, et il y en a un paquet ???

Je ne vois pas trop comment on peut être architecte/... sans se mettre à jour et pratiquer avec aisance (ce qui implique de coder souvent)

Quand je décris mon boulot je dis souvent que je suis un internel étudiant... alors oui des fois c'est usant mais c'est passionnant

J'abonde dans le sens étudiant, je dis toujours qu'il y a 3 métiers où tu étudies toute ta vie : Médecin, Homme de loi et Développeur.

Par contre un architecte n'a pas forcément besoin de connaitre toutes les dernières technos, sdk et api en vogue. Ils doit à mon sens comprendre les problématiques du projet et mettre en œuvre une architecture qui y répond. Plusieurs patterns ou design répondent déjà à des nécessités d'architecture, il faut les connaitre et savoir quand les appliquer, la réside sa force à mon sens. Une api ne fera que simplifier certains points...

[Aqualys]

Ceci dit, je travaille depuis 2 ans en Cobol (mainframe) et le discours selon lequel il faut toujours tout réécrire n'a pas du tout le même impact qu'en micro-informatique, on est beaucoup mouins exhubérant, on va dire.

La maintenance n'a pas la cote, c'est pourtant l'essentiel du travail en
développement.

Effectivement, l'environnement système ne permet pas toujours de pouvoir réécrire sans une lourde charge, mais c'est très drôle de voir un 'petit jeune' arriver dans une équipe et dire qu'il vaut mieux refaire le modèle de données car mal conçu ou mutualiser telle ou telle fonction pour une meilleure maintenance... sans tenir compte des facteurs d'origine et des objectifs d'exploitation.

Je crois en effet que les développements ne sont plus 'nouveaux' mais des extensions des SI en production et que la connaissance commence par la compréhension de l'existant. Et puis chercher et corriger un bug dans une appli conçue par des gens qui ne sont plus en place, avec une doc minimaliste ; quel challenge et quel pied !

[Darkzinus]

Effectivement, l'environnement système ne permet pas toujours de pouvoir réécrire sans une lourde charge, mais c'est très drôle de voir un 'petit jeune' arriver dans une équipe et dire qu'il vaut mieux refaire le modèle de données car mal conçu ou mutualiser telle ou telle fonction pour une meilleure maintenance... sans tenir compte des facteurs d'origine et des objectifs d'exploitation.

Je crois en effet que les développements ne sont plus 'nouveaux' mais des extensions des SI en production et que la connaissance commence par la compréhension de l'existant. Et puis chercher et corriger un bug dans une appli conçue par des gens qui ne sont plus en place, avec une doc minimaliste ; quel challenge et quel pied !

Totalement d'accord ! Le côté compréhension de code est très intéressant et nécessaire je pense pour progresser. En Mainframe typiquement je pense qu'avoir fait de la maintenance est indispensable pour développer correctement et comprendre/ intégrer les enchaînements (notamment dans les loooooongues chaînes BATCH).

[erwanlb]

D'autre part j'adhère a cette "maxime" : Pas touche à du code qui marche

Quand ça marche mieux c'est bien aussi d'y toucher

[LSMetag]

suis bien d'accord avec vous on pense pouvoir tout réécrire croyant
faire mieux ...ou simplement croyant que c'est plus facile de reprendre que de chercher à comprendre
D'autre part j'adhère a cette "maxime" : Pas touche à du code qui marche

Je suis à moitié d'accord avec ça. Oui on ne touche pas à un code qui marche dans une application d'entreprise ! Car le risque de créer des régressions (qui ne seront pas testées) n'est pas négligeable. Et les régressions, c'est très mal vu et surtout ça peut avoir des conséquences graves ! Et comprendre un existant est très important pour monter en compétence.

Par contre, je ne suis pas d'accord pour qu'on se la ferme quand on voit quelque chose de dégueulasse, qui risque d'entraîner des bugs, des problèmes de performances ou simplement une difficulté de maintenance.

Il faut savoir sonner des sirènes d'alarme auprès des chefs quand le problème n'est pas encore trop étendu. S'il ne s'agit pas de réécrire toute l'appli, ça peut se négocier.

Les jeunes qui arrivent sont enthousiastes et déchantent quand ils voient la gueule d'un code en entreprise...
Ce fut le cas pour moi et c'est vrai qu'au début j'étais comme ces jeunes qui disaient "ça c'est pourri il faudrait le refaire", mais je n'avais pas du tout le recul pour comprendre le fonctionnement en entreprise.

Le problème, c'est qu'une bonne partie des développeurs codent pour que ça marche (job alimentaire), peu importe comment ça marche, si ça va marcher dans l'avenir, si ça va être facile à maintenir, si ça va pouvoir s'interfacer avec une éventuelle appli que le demandera, si quand un bug se produira on pourra le débusquer,...

C'est pour ça que je préfère les startup qui démarrent sur des projets pas trop gros, malléables, et surtout en général sont passionnés et font des choix techniques intéressants.
Dans les plus grosses entreprises, t'as toute une machinerie assez rigide. Et c'est pas vraiment les développeurs qui conçoivent leur appli, mais plutôt des commerciaux.
T'as aussi un historique qui colle à la peau de l'entreprise et rend toute évolution difficile. Les applications ont souvent pas mal d'années.

[Jitou]

J'ai 40 passé et je code toujours avec autant d'enthousiasme que lorsque j'avais 20 ans !

J'ai pourtant essayé de me faire à l'idée que les années passant je devais être chef de projet car c'était dans l'ordre des choses et ma direction m'a toujours poussé en ce sens et bien rien à faire dès que je peux je mets les mains dans le cambouis c'est viscéral, c'est ce que j'aime le plus et je n'envisage pas une seconde aller au taffe faire des trucs chiants donc...

Aujourd'hui je sais faire les deux, coder dans les règles de l'art, gérer une équipe projet, prodiguer des conseils en archi et faire de l'analyse fonctionnelle. D'ailleurs j'aime bien alterner mes missions pour toujours avoir du pure développement dans mon travail. Sinon je regarde toujours un peu d'un oeil médusé mes collègues architectes fonctionnel ou chef de projet si éloignés de la technique et qui pour certains savent à peine se servir d'Excel, se sont souvent ceux-là qui méprisent les développeurs (pendant ma carrière j'en ai entendu des vertes et des pas mûres) ...

après toutes ces années je sais une chose, c'est que chef de projet c'est d'abord gérer les problèmes et la merdes des autres (en plus de la sienne) car malheureusement j'ai vu le niveau des développeurs considérablement baisser en 10 ans, donc plus de bugs et de malfaçons grossières, des délais largement dépassés sont à déplorer dans les projets et qui doit aller au feu, faire des heures à n’en plus finir pour calmer le client mécontent et sa propre direction impatiente ? Non je n'envie pas les chefs de projet d'aujourd'hui, je préfère encore créer et me taper de la conception UML à réfléchir sur la meilleur manière de répondre à un pb donné, perdu dans mes abstractions, d’ailleurs je ne conçois pas la programmation comme un travail mais plutôt comme un loisir ;-)

Dans ce métier je regrette juste une chose c'est le salaire des développeurs qui s'est réduit au fil des ans et ce en raison de l'arrivée massive de jeunes diplômés sur le marché qui acceptent sans rechigner le premier job à 2000e net. Mais cela va changer dans les années à venir lorsque l'industrie informatique arrivera enfin à maturité.

[pcaboche]

Dans ce métier je regrette juste une chose c'est le salaire des développeurs qui s'est réduit au fil des ans et ce en raison de l'arrivée massive de jeunes diplômés sur le marché qui acceptent sans rechigner le premier job à 2000e net.

2000€ net ? En tant que jeune diplômé, quand tu demandes 2000€ net, t'as l'impression de demander la lune !

Les recruteurs tirent les prix vers le bas. Certains acceptent malgré tout. Parmi ceux qui acceptent, t'en as des tellement mauvais qu'ils se font jeter au bout de 6 mois...

Pour le reste, je suis d'accord avec toi (sutout pour les architectes fonctionnel et chefs de projet qui ne savent pas se servir d'Excel et méprisent les développeurs).

[erwanlb]

2000€ net ? En tant que jeune diplômé, quand tu demandes 2000€ net, t'as l'impression de demander la lune !

Les recruteurs tirent les prix vers le bas. Certains acceptent malgré tout. Parmi ceux qui acceptent, t'en as des tellement mauvais qu'ils se font jeter au bout de 6 mois...

Pour le reste, je suis d'accord avec toi (sutout pour les architectes fonctionnel et chefs de projet qui ne savent pas se servir d'Excel et méprisent les développeurs).

2000€ net dans une SSII ou une petite boite ?

[Golgotha]

À tel point qu’en France, être encore développeur à plus de 30 ans est pratiquement synonyme d’échec

à force de le dire on va finir par le penser, et ce thread va y contribuer un peux plus, ça me désole.

Quand je lis :

Les réponses seront diversifiées entre les gros noms comme « Chef de projet, Architecte, etc. »

J'avais fait un billet un peu sur ce sujet, alors pour moi un chef de projet ou encore pire, un Architecte, sont des personnes avec des connaissances approfondies de leur métier, avec beaucoup d’expérience. Comment peut ont penser devenir Architecte logiciel sans avoir codé ?

Un métier ingrats ? Non, C'est un métier passionnant, et de passionné. Je ne parle pas du code Cobol qu'on nous demande de faire évoluer pour prendre en compte la loi n° 17623, ou faire une DAO à la main.. Si vos journée consiste à ça, premièrement je ne sais pas si on peu vous appeler développeur (si vous transformez du pseudo-code en code sans trop réfléchir dans des programmes qui ont 10 ans), j’appellerai plutôt ça un traducteur ou un ouvier, puisque ça tout le monde saura le faire, étude ou pas, tout à déjà été pensé par d'autre équipe. Le développeur est capable lui de concevoir un programme de A à Z, de se former sur les technologies qu'il doit mettre en œuvre, de mettre en place des paternes de plus en plus évoluer au fil de ça carrière, comme un compagnon qui doit parcourir la France pour apprendre différentes techniques en 10 ans puis réaliser un chef d’œuvre, il faut bien quelques années à un développeur pour découvrir les langages qu'il aime, puis encore quelques années pour se perfectionner dans ces langages. Ce n'est pas un métier qui s’apprend dans les livres ou dans des vidéos, il faut le pratiquer quotidiennement, être curieux des techniques des autres, partager.. etc pour qui aime faire partie d'une communauté, c'est peut être la plus grande communauté qui existe dans un domaine, avec beaucoup de partage et de savoir faire, dans le monde entier.

Alors, mon point de vue se résume à ça : un développeur à 30 ans, il commence à savoir bien coder.

[Arnard]

Est-ce que faire du CRUD est enrichissant ? Car quand on parle de pisseur de code, le CRUD représente une part assez importante, et pas la plus fun.... Pour peu qu'on ait un outil pour générer une partie du code à la main, il reste quoi ?