Discussion :

[dukoid]

les tests unitaires c'est de la merde.
durant le développement si tu veux refaire les choses parceque tu remarques que tu peux faire mieux , tu te dis: putin de merde, si je veux refaire mon code, faut que je me retape l'écriture de ces tests à la cons de TDD de merde ! alors tant pis, j'abandonne...

par contre, faire les tests à la fin QUE pour des fonctions ou des calculs importants, d'accord !
et vouloir tout tester c'est une aberration, une perte de temps.


les tests fonctionnelles ça c'est important ! j'adhère

[kilroyFR]

les tests unitaires c'est de la merde.
durant le développement si tu veux refaire les choses parceque tu remarques que tu peux faire mieux , tu te dis: putin de merde, si je veux refaire mon code, faut que je me retape l'écriture de ces tests à la cons de TDD de merde ! alors tant pis, j'abandonne...

par contre, faire les tests à la fin QUE pour des fonctions ou des calculs importants, d'accord !
et vouloir tout tester c'est une aberration, une perte de temps.


les tests fonctionnelles ça c'est important ! j'adhère

Totalement d'accord avec toi la dessus; enfin quelqu'un de pragmatique et non pas dogmatique comme c'est souvent le cas maintenant.
Les tests unitaires ca rassure les devs mais ca ne teste que les choses les plus simples - souvent ceux pour lesquels il n'y a pas beaucoup d'intelligence dans le code.
Les use case complets pour realiser des tests d'integration/fonctionnels sont pour moi ce qu'il y a de plus essentiels (et ce n'est pas une perte de temps).

[pmithrandir]

Ok effectivement je croyais que faisais allusion a une gratification supplementaire.
Comme deja dit, ils disposent de tout (outillage, environnement), participation active au fonctionnel/technique, deplacements etc.
Le constat etant que pour la plupart seule la technique les interesse (et essaye ensuite d'y trouver une justification en deformant le besoin fonctionnel pour justifier l'utilisation des choix technos ou archi - bref ce n'est plus la technologie qui subvient aux besoins fonctionnels mais le contraire).
C'est par ce genre de comportement repeté x nb projets qu'on a decidé de reduire leur tache a du travail bete puisqu'ils n'apportaient pas de reponses a nos demandes mais essayaient de deformer notre demande pour placer leurs envies (et ca derivait sur chaque plateau, donc multiplication des sujets, egarements inutiles etc).
Tout n'etait pas mauvais pour autant mais dans la grande majorité c'etait du superflu (invendable de plus car non exprimé par client).
Voila. Notre gestion de projet est plus directive mais elle a l'avantage d'etre canalisée. Moins de surprises. On a pu baisser la pretentions des devs; eux s'y retrouvent nous aussi et on livre ce qu'on a vendu, sans chichis. Moins de devs, plus d'executants et un pole technique d'architectes (service innovation) tres reduit qui envisagent des evolutions avec l'idee de la continuité du produit (evolutivité en douceur, migration, validation des innovations et intégration dans archi en cours, support au marketing pour proposition solution innovante etc).
Bref on s'eparpille moins, on maitrise plus facilement et les sujets sensibles sont ultra localisés. Enfin ca marche depuis 6 ans comme ca et on ne s'en plaint pas; ca marche (pourvu que ca dure).

Oui mais tout laisser dans les mains des devs jusqu'a la livraison/deploiement sur site ca n'est pas imaginable. On ne fait pas des logiciels pour nous mais pour des clients. A ce jour aucun de nos clients ne nous permettrait de faire du deploiement automatisé sur une PROD toutes les semaines. L'acces aux infras est strictement reglementé. On a des lots planifiés tous les mois avec du fonctionnel attendu.
Ceux qui font de la maintenance sont egalement sur plateau dédié toutes affaires. Generalement ils sont passés par l'etape de dev donc sont aguerris.
Ils sont sur meme infra que les autres. Nous ne pouvons acceder aux infras des clients que via VPN et lorsque le client decide de nous autoriser un deploiement sinon impensable de prendre le risque de mettre le wild dans des archis de prod (meme si en micro services, les dependances entre composants/api sont reelles, donc on ne met jamais a jour qu'une simple DLL comme on le lit dans la litterature). On a plus de 100 microservices fonctionnels.
DevOps ca va bien quand tu deploies des logiciels interne a ta boite (comme le font amazon, les grands comptes pour des applis internes etc). La partie deploiement n'est automatisée chez nous que pour nos tests (mais jamais vers les infras de PROD). Contractuellement interdiction d'acces en direct de maniere automatisé chez nos clients.

Je suis architecte (dans un petit groupe d'architectes - je suis de formation ecole d'ingenieurs EPITA a la base) dont la fonction principale est la conception/realisation de templates de logiciels (histoire que nos applis suivent toutes les memes regles, meme look, memes composants communs etc), de developpement de composants de haut niveau vus comme des boites noires pour les devs.
Donc on anticipe leurs besoins en connaissant le fonctionnel attendu, les technos en place ou celles retenues pour le projet (lorsque le client a des exigences particulieres imposées). Ils ne font principalement que de l'assemblage. C'est ce que permet l'informatique en 2018 avec une liberté qu'on n'avait pas avant.

Les problématiques complexes restent de notre domaine (ex: JAMAIS on ne va les laisser faire des deploiements en PROD directement, l'ajout de nouvelles technos ou modification de l'archi reste de notre perimetre; ce doit etre transparent pour eux).

On ne fonctionnait pas comme ca il y a 6 ans. On est toujours par plateau mais on a beaucoup moins de surprises a la fin. Celui qui sort du cadre se fait rappeler a l'ordre. Tyrannique d'une certaine façon mais pour une partie des devs qui ne sont pas des creatifs et qui ont besoin de guides ou tout simplement toujours le besoin qu'on leur tienne la main c'est ideal; ils deroulent. On a principalement besoin de bras. Le metier s'est uberisé, comme les autres. Le dev est a la portee de quiconque desormais. J'ai moi meme dans mon entourage des gens developpant (certes a leur niveau) des applications android sans qu'ils n'aient pour autant eu la formation adequate. L'autoformation pour des gens motivés et la richesse des supports disponibles permet a quiconque, motivé, curieux d'etre developpeurs aujourd'hui. Les bonnes pratiques arrivent comme dans tout metier en pratiquant et en suivant des templates.
C'est cette optique qu'on a retenue. Nos devs sont en offshore mais francophone. Ils sont aussi bons que pas mal de gens que j'ai pu rencontré dans ma carriere. Ils n'ont pas a rougir, loin de là.
Ils ne font pas de choses compliquées mais plutot des choses dont le périmetre technique/fonctionnel est ciblé. On ne cherche plus a les interesser totalement au fonctionnel. On fonctionne en micro services donc le perimetre fonctionnel est ultra bete. La complexité intrinseque a ces archis ils n'en ont aucune connaissance ni visibilité; c'est notre boulot de le gerer; eux je dirai c'est vulgairement de pisser du code. On a mis en place pas mal de templates pour generation de codes en respectant/implementant les patterns disponibles. Le code genere leur sert de base; ils s'autoforment en meme temps.

Si tu ne cadres pas un dev, naturellement il aura tendance a aller vers la facilité et le plaisir de coder. Il a son temps perso chez lui pour sa. Comme deja dit ils ont moyen de valoriser leur creativité et proposer des choses mais pas dans le cadre des heures de boulot. Il y a des primes etc. et eventuellement la possibilité d'intégrer des composants dans notre framework maison donc une forme de reconnaissance.
De toutes les methodes de dev rencontrées a ce jour, c'est la seule reellement efficace et on le constate au jour le jour. Nous n'avons a ce jour quasiment plsu de mauvaises surprises et les delais/qualités sont respectés. Archi micro services + dev off shore ca fonctionne idealement je dirai.
Voila ce n'est que l'experience dans ma boite mais je sais que pas mal de boites alentours se tournent vers ces archis car elles ont compris l'interet qu'on pouvait en retirer tres rapidement.

Si vous etes intéressé par un feedback, lisez la suite.

Tous vos post reflete un état d'esprit. Je ne sais pourquoi, mais vous donnez l'impression d'etre supérieur aux autres, d'assimiler tous les dev aux même travers.
Ce n'est pas une équipe qui est dénaturée, mais toutes les équipes... De mon coté, j'ai tendance a essayer de trouver lr point commun a ces situations, et ce n'est pas obligatoirement qu'ils sont tous dev...

De mon experience, j'ai toujours rencontré des dev qui voulaient en savoir plus. Même ceux qui pretendaient le contraire creusait le besoin fonctionnel quand on leur en donnait l'occasion.

Oui, ils aiment parfois développer des choses nouvelles, mais souvent c'est parce que :
- leurs suggestions honnetes ne sont jamais acceptées(ce n'est pas une priorité métier)
- on les prend pour de la merde, donc ils construisent leur CV.

En général, ca va de pair avec un turn over important.

Je ne vous connais pas, vous n'aurez peut être rien a faire de mon feedback, mais je vous conseille de faire une introspection forte de votre manière de travailler, de l'image que vous vehiculez, etc... Demandez juste des feedback par exemple tous les 6 mois 2 ou 3 fois de suite. Et réagissez par un plan d'action aux difficultés remontées. Vous serez je pense étonné de la justesse de certains retour, et surement de leur coté généralisé.

Bon courage si vous prenez ce chemin, il va être dur à suivre et difficile à encaisser... mais dans 18 mois je peux vous promettre que vous serez à un tout autre niveau professionnel.

[kilroyFR]

Je ne vous connais pas, vous n'aurez peut être rien a faire de mon feedback, mais je vous conseille de faire une introspection forte de votre manière de travailler, de l'image que vous vehiculez, etc... Demandez juste des feedback par exemple tous les 6 mois 2 ou 3 fois de suite. Et réagissez par un plan d'action aux difficultés remontées. Vous serez je pense étonné de la justesse de certains retour, et surement de leur coté généralisé.

Bon courage si vous prenez ce chemin, il va être dur à suivre et difficile à encaisser... mais dans 18 mois je peux vous promettre que vous serez à un tout autre niveau professionnel.

lol, non je ne m'en fous pas mais je le trouve bien naif et vous n'ecoutez pas; cela fait 22 ans que je suis dans l'informatique; a cette epoque les devs etaient interessés par la finalité de qu'ils faisaient et ne s'arretaient pas au langage/techno/outils.
Aujourd'hui c'est l'inverse; j'ai vu le changement au fil des années. La techno/outils/methode est presque considérée comme une fin en soi; ou l'on se retrouve face a des gens pleins de dogmes et d'ideologies. Combien de fois on a entendu des discours de cours de maternelles (java vs c#, oracle vs sqlServer etc.) sans aucun interet.
Visiblement vous ne lisez pas ce que j'ai ecrit. Tout ce que vous proposez a ete testé; en vain, on ne peut pas changer la nature d'un dev qui aura naturellement tendance a faire ce qui l'interesse. Si on est arrivé a cette conclusion c'est le resultat de multiples tentatives, ajustements pour se rendre compte de l'echec. On veille a la bonne communication et on reste a leurs ecoute mais en aucun cas ils ne derogent a ce qu'ils sont censés faire.
La seule chose qui fonctionne c'est ce qu'on a mis en place, juste un constat sur ces 6 dernieres années. Pas besoin de perdre 18 mois pour constater que ca ne fait rien avancer.
J'ai encaissé largement plus de choses que ce que vous pouvez sous entendre.
Le turn over ? ce n'est plus un probleme. l'expertise d'un dev ? ce n'est plus une contrainte.
Et non je ne prends personne de haut, je ne fais que constater la realité; un developpeur (codeur) reste un ouvrier dans l'echelle des professions en informatique; que votre ego vous interdise de le penser ou pas. C'est la profession la plus facile a uberiser et les archis modernes le permettent avec une grande facilité sans risques (contrairement a ce qu'on realisait auparavant).
Est-ce qu'on demande a un ouvrier sur une chaine de production de connaitre comment fonctionne une voiture ? non on lui demande de bien faire la 'micro' tache qui lui incombe.
Pour les archis micro service c'est le meme principe. La production de logiciel est une industrie comme une autre.

[Pyramidev]

Parmi les principes sous-jacents au Manifeste agile, on a :

• Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  (C'est moi qui mets motivé en gras.)
• Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

Mais, pour que ça marche, il faut des développeurs à la fois compétents et motivés pour répondre au besoin.
À l'embauche, comment distinguer de manière la plus fiable un candidat qui cherche à répondre au besoin d'un candidat je-m'en-foutiste ?
Il ne faut pas que les je-m'en-foutistes deviennent majoritaires. Sinon, ça sera contagieux.

D'ailleurs, kilroyFR, quelle est la méthode de recrutement de ton entreprise ? Peut-être qu'il y a eu à la fois un problème de recrutement et de la malchance.

[Gluups]

lol, non je ne m'en fous pas mais je le trouve bien naif et vous n'ecoutez pas; cela fait 22 ans que je suis dans l'informatique; a cette epoque les devs etaient interessés par la finalité de qu'ils faisaient et ne s'arretaient pas au langage/techno/outils.
Aujourd'hui c'est l'inverse; j'ai vu le changement au fil des années. La techno/outils/methode est presque considérée comme une fin en soi; ou l'on se retrouve face a des gens pleins de dogmes et d'ideologies. Combien de fois on a entendu des discours de cours de maternelles (java vs c#, oracle vs sqlServer etc.) sans aucun interet.

Si vraiment c'est ça alors je dois confirmer qu'effectivement je suis de la vieille école. J'essaie de me mettre dans la peau de l'utilisateur, j'ai appris des méthodes qui m'aident à poser les bonnes questions pour ça. En dehors du développement agile il y a un tunnel sans beaucoup de communication, et à la fin la satisfaction du client confirme que les questions posées au début étaient les bonnes.

Si ça c'est démodé alors peut-être que ça explique dans une certaine mesure mes difficultés à trouver du travail. J'ai droit à des surprises. Pendant un entretien, l'interlocuteur se dit satisfait, et il faut rappeler un mois plus tard, que j'ai passé à réviser et mettre à jour les webparts, pour apprendre que le jugement était que j'étais sur des technologies dépassées. Après ça il m'a fallu trois jours pour être au top sur les WebAPI, pourquoi pas dire tout de suite ce qu'on veut ?

[vertex.3F]

lol, non je ne m'en fous pas mais je le trouve bien naif et vous n'ecoutez pas; cela fait 22 ans que je suis dans l'informatique; a cette epoque les devs etaient interessés par la finalité de qu'ils faisaient et ne s'arretaient pas au langage/techno/outils.
Aujourd'hui c'est l'inverse; j'ai vu le changement au fil des années. La techno/outils/methode est presque considérée comme une fin en soi; ou l'on se retrouve face a des gens pleins de dogmes et d'ideologies. Combien de fois on a entendu des discours de cours de maternelles (java vs c#, oracle vs sqlServer etc.) sans aucun interet.

si vous exerciez il y a 22 ans, souvenez-vous des technos de l'epoque;
comparé à aujourd'hui, le panel des technos informatique etait très restreint, de facto les developpeurs etaient plutot "canalisés" sur ce plan je pense;
il me semble aussi que les profils des développeurs etaient moins "techniques", et davantage orientés "métier";
du coup, mécaniquement, les discours de maternelles (comme vous les nommez) portaient sur d'autres sujets...

Et non je ne prends personne de haut

Chacun de nous fait comme il peut pour raisonner aux niveaux d'abstraction auxquels il peut accéder. Celui qui serait hautain ne doit pas oublier qu'il s'exposerait à être détesté (par exemple).

La production de logiciel est une industrie comme une autre.

Ca me fait mal (au yeux) de lire ça sur un forum spécialisé en informatique, pire (mal plus bas) venant de la part d'un architecte qui met en avant 22 années d'expérience.
L'info est mon second métier après l'industrie, ça tombe bien... et je ne suis pas seul à estimer que le premier domaine (le dév informatique) ressemble davantage à du prototypage qu'à un process industriel. Au passage j'exerce mon métier de développeur depuis 20 ans (moi aussi je peux frimer d'avoir corrigé et créé des bugs depuis si longtemps...).
J'ai trouvé un peu de lecture récente (premiers liens via recherche google) :

• Pourquoi l’industrialisation informatique ne marche pas (1ière partie) : https://fr.linkedin.com/pulse/analys...pas-poudevigne
• Pourquoi l’industrialisation informatique ne marche pas (deuxième partie) : https://www.linkedin.com/pulse/analy...s-poudevigne-1

[Marco46]

Totalement d'accord avec toi la dessus; enfin quelqu'un de pragmatique et non pas dogmatique comme c'est souvent le cas maintenant.
Les tests unitaires ca rassure les devs mais ca ne teste que les choses les plus simples - souvent ceux pour lesquels il n'y a pas beaucoup d'intelligence dans le code.

Normalement on fait exactement l'inverse, on a besoin de TU (au sens strict, c'est à dire totalement isolé de l'extérieur de la fonction à tester) lorsque c'est compliqué et qu'il y a beaucoup de cas. Sinon on prend l'approche de Ian Cooper où les TU doivent servir à découvrir l'implémentation sur la base de prérequis fonctionnels, en supposant que l'application est suffisamment bien structurée pour garder les IO à l'extérieur du périmètre à tester (clean architecture, hexagonal architecture, etc ...).

Les use case complets pour realiser des tests d'integration/fonctionnels sont pour moi ce qu'il y a de plus essentiels (et ce n'est pas une perte de temps).

Un test d'intégration sert à vérifier les cas passants entre deux systèmes, globalement un cas passant et un cas d'erreur. C'est à dire un back et un front, deux webservices l'un avec l'autre, un back et une base de données, etc ...On ne teste pas le fonctionnel avec de tels tests ils sont beaucoup trop chers à exécuter.

La logique fonctionnelle doit être testée exclusivement en unitaire, c'est à dire en mockant les I/O (pas forcément les collaborateurs internes à la logique) parce que c'est extrêmement rapide à exécuter.

Je subodore que ce que tu appelles test fonctionnel est en réalité test end-to-end dont le rôle est de traverser toute la stack avec des cas passants et en aucun cas de tester tous les corners cases complexes du métier.

Sur ce je voudrais rebondir sur ce commentaire :

Après, je vous rejoins sur l'inutilité d'un bac+5 pour faire du dev. La plupart du temps un bac +3 suffirait largement et genererait moins de frustration.

Je ne vois pas du tout en quoi 2 ans d'études en plus ou en moins changerait quoi que ce soit sur la frustration. Le problème c'est qu'on est tous contraints de travailler constamment avec une majorité de débutants pour qui toutes ces notions sont une découverte (et je parle pas du management qui est par essence incompétent sur ces sujets et qui croit pertinent de venir y mettre son nez). J'ai moi-même beaucoup de mal à appliquer et faire appliquer tous les principes que j'évoque en mission tant le niveau est faible. Mais c'est normal, il ne faut pas oublier que nous sommes dans une industrie extrêmement jeune, et IMHO la frustration vient surtout de là.

[Grogro]

Je ne vois pas du tout en quoi 2 ans d'études en plus ou en moins changerait quoi que ce soit sur la frustration. Le problème c'est qu'on est tous contraints de travailler constamment avec une majorité de débutants pour qui toutes ces notions sont une découverte (et je parle pas du management qui est par essence incompétent sur ces sujets et qui croit pertinent de venir y mettre son nez). J'ai moi-même beaucoup de mal à appliquer et faire appliquer tous les principes que j'évoque en mission tant le niveau est faible. Mais c'est normal, il ne faut pas oublier que nous sommes dans une industrie extrêmement jeune, et IMHO la frustration vient surtout de là.

En un sens si, puisqu'on fait un bac+5 pour faire un travail d'ingénieur (qu'on ait le titre ou non, une énième aberration franco-française sur laquelle on ne va pas revenir), avec une paye d'ingénieur, pas pour faire un boulot de technicien, simple exécutant à qui il est interdit la moindre initiative, même si cela lui sera reproché en entretien annuel ensuite pour prétexter le gel du salaire pendant N années, avec une paye inférieure à un technicien. Les métiers de l'informatique ont quelque chose de pathologique en France.

La frustration des débutants vient aussi que 90% des projets sont de la maintenance, parfois chez le client, parfois en CDS. Sans doc, sans normes de codage, allant à l'encontre de toutes les bonnes pratiques qu'on leur a apprises à l'école, avec une architecture spaghetti, sans ORM (ou plusieurs bouts d'ORM maison qui se télescopent), et un code dégueulasse qui relève d'une sédimentation de micro-décisions aberrantes sur des années. Parce que des dizaines de presta s'y sont succédé au fil des ans. Et sur des technos ancestrales genre java 6 avec des bibliothèques maison qui sont des copier-coller de bouts de bibliothèques standard, mais qu'il est interdit d'utiliser pour des raisons X ou Y (qui ont pu avoir une légitimité à une époque mais qui semblent arbitraires). Avec genre du Struts pour le front. Ou devbooster (ceux qui ont bossé pour le crédit mutuel comprendront). Mais ce code marche, et le refondre ça prend énormément du temps, et c'est un gros risque.

Pour en rajouter à la frustration, pas mal de jeunes diplômés ont pu faire leur alternance dans une vraie entreprise avec de vrais projets. Quand on se retrouve ensuite à faire de la merde indigente en SSII parce que c'est 90% du marché de l'emploi, pour une paye indigente, ça file une énorme claque. Et j'en ai vu pas mal devenir cyniques ou désabusés en quelques mois. Ou devenir simplement mauvais, sans aucune rigueur, alors qu'ils semblaient prometteurs avec de bonnes capacités. Ce qui génère aussi beaucoup de frustrations côté client puisque ces ressources leur ont été vendues comme "experts" par le commercial du viandard. Or ces SSII embauchent à 80% des débutants (jeunes diplômés ou moins de 2 ans d'expérience). Et si le commercial est honnête, c'est la SSII concurrente qui décroche le contrat. Un gros contrat perdu ça fait parfois TRES mal (cf les mésaventures de Sopra Steria Banking la semaine dernière).

Quand on fait de la presta en SSII, on bosse souvent sur des grands comptes. Ce sont des projets intéressants quand on sort de la technique pour appréhender le métier, mais qui sont abrutissants au possible pour un développeur, qu'il soit bon ou mauvais (et s'il est bon, en quelques mois il deviendra au mieux moyen tellement il sera sous utilisé). Et les débutants découvrent toutes les rigidités de l'entreprise française ultra verticalisée, son management franco-français catastrophique, la culture du présentéisme, ses silos métiers étanches, où la moindre demande d'information qui doit passer par le N+2, puis par le chef de service rival du N+2, dont les dents rayent le parquet pour se faire bien voir du N+3 et du N+4. Découvrent empiriquement le principe de Peter voire de Dilbert, les délires de la cellule marketing sous coke (). Les spécifications fantaisistes, lacunaires, ou contradictoires, qu'on leur demande d'appliquer au pied de la lettre le plus rapidement possible.

Il y a aussi un gros malentendu dès l'école puisque le développement n'est qu'une composante de notre métier. Notre métier, c'est la prestation de services pour le tertiaire. Nous sommes en quelque sorte tous des consultants low cost, et le développement n'est qu'un outil à mettre au service du métier et de l'utilisateur final. Beaucoup de dev ne le comprennent jamais. De mon point de vue, c'est pourtant l'articulation entre le métier et la solution logicielle qui constitue la partie la plus intéressante du métier. C'est pour ça que sont faites les architectures micro-services.

On est je crois le seul pays au monde où le SI n'est pas considérée comme un métier de l'entreprise mais comme un coût et une charge à externaliser le plus possible. On a une culture d'entreprise maladive jusqu'à l'os en France.

[el_slapper]

(.../...) Notre métier, c'est la prestation de services pour le tertiaire. Nous sommes en quelque sorte tous des consultants low cost, et le développement n'est qu'un outil à mettre au service du métier et de l'utilisateur final. Beaucoup de dev ne le comprennent jamais. De mon point de vue, c'est pourtant l'articulation entre le métier et la solution logicielle qui constitue la partie la plus intéressante du métier.

Dans mes bras!!! Faire de la technique, tout le monde peut le faire, et une fois que c'est fait, ça n'est plus à faire. Par contre, faire face à un besoin client sans cesse innovant, et l'accompagner, ça c'est rigolo.

On est je crois le seul pays au monde où le SI n'est pas considérée comme un métier de l'entreprise mais comme un coût et une charge à externaliser le plus possible. On a une culture d'entreprise maladive jusqu'à l'os en France.

Là aussi tu prêches un convaincu. Il y a des ilôts ou ça n'est pas vrai, mais c'est vraiment une plaie, le management à la Française. Après, j'ai connu un directeur de grande banque Française(qui traitait le président Sarkozy comme un subalterne, accessoirement...) qui n'hésitait pas à téléphoner tous les soirs à des chefs de projet qui pilotaient des projets stratégiques(vraiment stratégique, hein, pas des jouets pour occuper le boss). Mais j'en ai vu un seul. Tous les autres.....

[Marco46]

En un sens si, puisqu'on fait un bac+5 pour faire un travail d'ingénieur (qu'on ait le titre ou non, une énième aberration franco-française sur laquelle on ne va pas revenir), avec une paye d'ingénieur, pas pour faire un boulot de technicien, simple exécutant à qui il est interdit la moindre initiative, même si cela lui sera reproché en entretien annuel ensuite pour prétexter le gel du salaire pendant N années, avec une paye inférieure à un technicien. Les métiers de l'informatique ont quelque chose de pathologique en France.

Un développeur ne peut pas être un simple exécutant, peu importe son niveau d'étude. Après que des gens dans le personnel de management pensent qu'un développeur a le même rôle qu'un ouvrier dans une chaîne de montage c'est un autre problème lié à l'incompétence du management en général.

En d'autres termes, il n'y a pas de travail dans le développement qui corresponde à celui d'un simple exécutant technique qui suit des instructions servilement, ça n'existe pas. Malheureusement, le problème c'est que des gens qui sont souvent à des postes de pouvoir et de décisions pensent que ça existe.

Il y a aussi un gros malentendu dès l'école puisque le développement n'est qu'une composante de notre métier. Notre métier, c'est la prestation de services pour le tertiaire. Nous sommes en quelque sorte tous des consultants low cost, et le développement n'est qu'un outil à mettre au service du métier et de l'utilisateur final. Beaucoup de dev ne le comprennent jamais. De mon point de vue, c'est pourtant l'articulation entre le métier et la solution logicielle qui constitue la partie la plus intéressante du métier. C'est pour ça que sont faites les architectures micro-services.

Le métier du développeur c'est de transformer une expression du besoin plus ou moins bien détaillée rédigée en langage naturel en spécifications (langage formel) permettant la génération d'un programme exécuté par une machine. C'est ça notre métier. Le fait que l'on soit prestataire pour une organisation ou en interne dans une organisation ça c'est relatif au poste, pas au métier. Dans les deux cas on est au service de l'utilisateur, simplement dans le cas de la prestation on est d'abord au service de notre propre entreprise et seulement après au service de l'utilisateur. Et ça c'est pas du tout relatif au métier, c'est relatif au poste (ta place dans l'organisation générale).

[DevTroglodyte]

On est je crois le seul pays au monde où le SI n'est pas considérée comme un métier de l'entreprise mais comme un coût et une charge à externaliser le plus possible. On a une culture d'entreprise maladive jusqu'à l'os en France.

Quoi, ça ne concerne pas tous les services à l'exception de la direction, ça ?

[maritime]

Bonjour,
Je livre mon expérience de vouloir faire le travail sois même.
N’étant pas développeur professionnel j'ai décidé il y a quelques années de développer moi même un programme spécifique.
Il s'agit du domaine de la navigation maritime plus précisément de Astro-navigation, car demander a un programmeur de vous faire un tel logiciel nécessite une présence (professionnellement compétant) pour épauler celui qui écrit le code, reste le test (débogage) qui demande pratiquement autant de temps que l’écriture du code.
Sauf que je ne suis pas encore sorti de l'auberge, c'est pour cela que j'ai utilisé le mot "épauler un programmeur professionnel".
les applications spécifiques sont toujours compliquées et longues a réaliser surtout quand il s'agit de sortir des sentiers battus.

[Gluups]

Bonjour,
Je livre mon expérience de vouloir faire le travail sois même.
N’étant pas développeur professionnel j'ai décidé il y a quelques années de développer moi même un programme spécifique.
Il s'agit du domaine de la navigation maritime plus précisément de Astro-navigation, car demander a un programmeur de vous faire un tel logiciel nécessite une présence (professionnellement compétant) pour épauler celui qui écrit le code, reste le test (débogage) qui demande pratiquement autant de temps que l’écriture du code.
Sauf que je ne suis pas encore sorti de l'auberge, c'est pour cela que j'ai utilisé le mot "épauler un programmeur professionnel".
les applications spécifiques sont toujours compliquées et longues a réaliser surtout quand il s'agit de sortir des sentiers battus.

En effet, pour des choses bien pointues il n'y a rien de tel que la double compétence. On n'en est pas encore tout-à-fait là à ce que je comprends ? Ça peut venir, c'est souvent comme ça que viennent les vocations.

En attendant, le succès dépendra d'une bonne entente entre les deux personnes, qui les aidera à mieux se comprendre, tout en soutenant leur motivation.

La difficulté, pour se replacer dans le fil de la discussion, est que probablement aucun des deux n'a de vague idée de combien il faudra de temps pour finir le projet (sauf à avoir fait au départ une présentation très efficace du besoin). Il reste donc à espérer que ça ne dépassera pas les moyens qui pourront être dépensés dessus.