Avez-vous déjà été énervé par un "responsable irresponsable" dans votre carrière de développeur ?

Gordon Fowler · 11/09/2009, 12h20

Avez-vous déjà été énervé par un "responsable irresponsable" dans votre carrière de développeur ?

Comme partout, il y en a des bons.
Mais aussi des mauvais.
Il y a des sympas.
Mais certains sont de vrais tyrans.
Il y en a des compétents.
Mais il y a aussi les incapables.

Loin de nous, donc, l'idée de jeter l'opprobre sur les responsables de projets logiciels.
Et encore moins de dresser le portrait d'une profession sans laquelle rien ne pourrait se faire !

Mais il faut bien admettre que beaucoup parmi ceux qui ne développent plus (... qui n'ont jamais développé ?), ont quelques travers particulièrement énervants... dont on peut se demander d'ailleurs s'ils ne sont pas catalogués dans un manuel du parfait "irresponsable" de projet :

1 - N'oubliez pas ! Vous savez tout mieux que tout le monde : donc c'est à vous de décider. Ne posez pas de cadre au développement, de cette manière vous pourrez rajouter en continu (et jusqu'au jour de livraison du programme !) les fonctionnalités supplémentaires que le client vous demande. Ne les discutez pas et ne prenez surtout pas en compte la road-map (ça pourrait le fâcher).
Résultat pour vous : un code qui ressemble à un plat de spaghetti truffé de bugs et des heures supplémentaires pour tenir les délais.

2 - Et si vous faisiez réinventer la roue à vos équipes ? : L'open-source c'est le mal. Personne ne peut le nier (cf. point 1). Même pour implémenter des fonctions basiques il est hors de question d'utiliser le "libre". C'est gratuit donc ça tue le business. C'est ouvert donc c'est pas sûr. Et d'ailleurs on ne sait jamais, un jour peut-être faudra-t-il payer des droits sur ces licences bizarres.
Résultat : Une semaine à coder ce que la terre entière a déjà fait mille fois.

3 - L'outil ne fait pas le travailleur, il n'y a aucune raison que les développeurs choisissent : Le développeur ne doit être impliqué que dans ce qui le concerne (choix de la couleur du clavier, marque de l'écran, etc.). Le bon manager impose framework, langage, et tout ce genre de chose (cf. point 1).
Résultat : Le confort de travail en prend un coup. Ce qui demanderait 3 jours de travail effectif peut prendre jusqu'à deux siècles.

4 - Une équipe qui tourne est toujours louche : Il y a souvent anguille sous roche. Dans ce cas, imposer une réunion pour tirer l'affaire au claire. Si vous ne trouvez rien, n'hésitez pas à en faire une bonne centaine. Vous verrez qu'en cherchant bien, ces équipes ne travaillaient pas selon le process décrit page 27 de l'annexe F du deuxième rapport de la Version 2.7.3.a du Manifeste Agile de votre société. Vous le saviez ! (cf. point 1)
Résultat : plus aucun résultat, l'équipe est en réunion.

5 - Ne passez pas mille ans à tester : Tester c'est de l'argent perdu. Ce qui est fait est fait. Vendez plutôt ! Si le produit ne fonctionne pas mettez le sur le dos du développeur, c'est lui le responsable des bugs non? Dîtes bien au client qu'une mise à jour est en cours et n'oubliez pas de passer un savon au développeur. Il se doit d'être à votre niveau d'excellence (cf. point 1).
Résultat : La qualité logicielle est proche de zéro et on vous accuse de mal faire votre boulot.

Soyons honnête, les responsables de projet ne sont pas comme ça.

Mais il vous est certainement arrivé d'en croiser au moins un qui a appliqué ces commandements...

Pas vrai ?

Et vous ?

Lequel de ces travers de responsable avez-vous croisés le plus souvent ?

Dîtes nous ce qui vous a le plus énervé dans votre carrière de la part d'un "responsable irresponsable" ?

Lire aussi :

Les 10 phrases qui rendent fou un informaticien : les avez-vous déjà entendues ?

g0up1l · 11/09/2009, 14h49

très bonnes remarques !

Maintenant, on peut aussi être énervé en tant que chef d'équipe par un développeur irresponsable ! En voici un manuel :

1 - ne perd pas de temps à sauvegarder tes sources ! C'est du temps de perdu et de toute façon tu as tout dans la tête !

2 - ne prend pas la peine de vérifier le numéro de la version que tu dois faire évoluer, ton chef n'avait qu'à te le dire !

3 - ne prend pas la peine de tester ce que tu livres, il sera toujours temps d'évoquer une maladresse involontaire !

4 - ne lis pas les specs ! Inutiles et dangereuses, elles ne font qu'alourdir la charge de travail !

5 - et surtout, ne rédige aucune doc ! L'utilisateur est un veau incapable de comprendre l'intuitivité de ta merveilleuse application

B.AF · 11/09/2009, 14h50

Personnellement, j'ai l'erreur #5 à mon passif.

batataw · 11/09/2009, 15h04

Citation:

3 - L'outil ne fait pas le travailleur, il n'y a aucune raison que les développeurs choisissent : Le développeur ne doit être impliqué que dans ce qui le concerne (choix de la couleur du clavier, marque de l'écran, etc.). Le bon manager impose framework, langage, et tout ce genre de chose (cf. point 1).
Résultat : Le confort de travail en prend un coup. Ce qui demanderait 3 jours de travail effectif peut prendre jusqu'à deux siècles.

Ca c'est une constante:
- Pourquoi un serveur de dev, vous developpez sur vos machines.
- Pourquoi un serveur d'intégration on a déja un serveur de Dev.
- Pourquoi de la mémoire, les autres s'en sortent avec 512Mo de mémoire sur leurs machines (pour info ils font de la bureautique)
- Je sais nous avons besoin de tester mais on le fera après la mise en prod,
on aura du temps

Vous avez parfois des managers qui n'ont pas suivi les nouvelles évolutions technologiques et ils sont toujours les décideurs dans leurs entreprises. Ils ne prennent même pas la peine d'emmener un développeur senior avec eux lors de réunions techniques. Ca peut créer des situations comiques ou désespérantes.

Le pire pour moi, c'est d'être en bout de chaine et donc d'être a fortiori le maillon faible. Quand un projet plante c'est forcément le développeur qui prend si le manager n'est pas solide et n'a pas su arrêter ou controller le flux des nouvelles demandes a faire pour hier.

Lung · 11/09/2009, 15h18

Citation:

Envoyé par g0up1l

5 - et surtout, ne rédige aucune doc ! L'utilisateur est un veau incapable de comprendre l'intuitivité de ta merveilleuse application

De toute façon, par définition, un utilisateur ne sait pas lire. Déjà que lire un message d'erreur est au-dessus de ses capacités ...
Donc, ça sert à rien.

LeSmurf · 11/09/2009, 15h22

Citation:

5 - Ne passez pas mille ans à tester : Tester c'est de l'argent perdu. Ce qui est fait est fait. Vendez plutôt ! Si le produit ne fonctionne pas mettez le sur le dos du développeur, c'est lui le responsable des bugs non? Dîtes bien au client qu'une mise à jour est en cours et n'oubliez pas de passer un savon au développeur. Il se doit d'être à votre niveau d'excellence (cf. point 1).
Résultat : La qualité logicielle est proche de zéro et on vous accuse de mal faire votre boulot.

Celle-ci est très fréquente. Quand les délais ou le budget sont un peu justes, cette étape a souvent tendance à sauter. C'est parfois même anticipé pour que l'offre "reste compétitive".

Il se produit alors exactement ce qui est décrit : Si une régression apparait, "Tu dois être plus rigoureux dans ton travail", "tu manques d'attention...". Si quelqu'un a l'insolence de rappeler qu'aucune politique de gestion de la qualité n'a été mise en place, tension et discours sur le fait "qu'il faut produire" et que "les développeurs doivent être rigoureux". Si les problèmes de qualité persistent, on se pose alors la question "de la ressource".

palnap · 11/09/2009, 18h05

Moi j'ai un peu de mal avec les responsables de projets qui n'ont jamais codé (oui, une analyse UML présentant le cas idéal ça fait pas tout) ou pas dans un gros projet :/ Ou qui considèrent jamais les spécificités d'un projet informatique (ben t'es pas capable de quantifier ton travail avant de définir les technos utilisées ?)

J'aurai rajouté celle-là : "n'oubliez pas de toujours plus en demander à vos salariés, s'ils sont capables de multiplier leur productivité par 4 pendant 15 jours en fin de projet, pourquoi pas éternellement ?"

grunk · 11/09/2009, 22h08

Citation:

N'oubliez pas ! Vous savez tout mieux que tout le monde

Ca c'est le classique et sans doute celui qui me sort par les yeux. Des specs jamais défini, on recode des truc trois fois car le client ou le boss change d'avis comme de chemise. Pour peu qu'on est plusieurs clients pour un même soft on en arrive à avoir une version par client ...

Citation:

4 - Une équipe qui tourne est toujours louche

Ou comment faire une réunion sur la productivité au lieu de l'être vraiment.

Citation:

2 - Et si vous faisiez réinventer la roue à vos équipes ?

La attention tout de même , open source ne veux pas dire qu'on peut faire ce que l'on veux. Intégrer un bout de code GPL (par exemple) dans son appli reviens a faire passer tous le code l'utilisant (au mininmum) en GPL. Pour bon nombre de boite il est impensable de diffuser son code source , donc obligation de recoder des choses existante

B.AF · 12/09/2009, 10h25

Citation:

Envoyé par palnap

Moi j'ai un peu de mal avec les responsables de projets qui n'ont jamais codé (oui, une analyse UML présentant le cas idéal ça fait pas tout) ou pas dans un gros projet :/ Ou qui considèrent jamais les spécificités d'un projet informatique (ben t'es pas capable de quantifier ton travail avant de définir les technos utilisées ?)

J'aurai rajouté celle-là : "n'oubliez pas de toujours plus en demander à vos salariés, s'ils sont capables de multiplier leur productivité par 4 pendant 15 jours en fin de projet, pourquoi pas éternellement ?"

Je suis d'accord avec toi. Mais il n'y a pas encore si longtemps quelqu'un m'a dit "tu codes à ton niveau????", et ben oui, on me le reproche, certains pensent que c'est idiot, moi pas. JE comprends ce que fait chaque personne des équipes, je connais leur limites techno, leurs limites métier, et ça me fait gagner du temps ! Ca sert à quoi sinon que je ne comprenne rien au boulot de mes équipes ? Ca réduit le temps de réunion, ça me permet de veiller aux formations mieux qu'avant, on progresse aussi en r&d...
Un chef de projet, ou un responsable IT qui ne comprend pas le métier de ses équipes est inutile. Il ne peut rien décider ou rien faire en autonomie, c'est juste une charge pour la boite. Mais bon, il y en a, tant mieux pour eux, mais la réalité est que leurs succès sont plus de l'auto-conviction sur des statistiques arrangées de powerpoint.

B.AF · 12/09/2009, 10h32

J'ajouterai pour envoyer une soufflante à tous les inutiles que l'informatique est le seul métier du monde où on accepte que des incompétents encadrent.
C'est terrifiant.
Pourquoi ?
De un, beaucoup ne savent pas quoi attendre du développement. Ce que j'appelle la "ruralité" de l'IT. Et c'est déjà le début des conflits
Cela améne à des gestion de la qualité qui coutent beaucoup et passent souvent à la trappe (qui n'a pas entendu l'expert fonctionnel dire "hors de question que je développe des tests, je ne suis pas technicien!")

Il serait temps que les informaticiens se ré-approprient leur métier, et que les RH arrêtent cette politique stupide de croire qu'une personne avec un background de manager opérationnel peut encadrer des projets techniques !

Une fois de plus, ce dysfonctionnement n'existe que dans l'informatique.
Dans un laboratoire pharmaceutique, les chefs de projet n'ont pas fait des sup de co, dans l'aéronautique, les chefs de projet n'ont pas fait un dess gestion des SI ou autre.

J'aimerai un jour que mon métier ne soit pas le dépotoir du management sous toutes ses formes qui servent de reclassement aux opérationnels qui n'ont pas réussi à s'affirmer et que l'on comprenne aussi que l'efficience d'une équipe n'est pas sa taille mais sa motivation et un niveau de formation constant.

Bref, un métier à révolutionner :

Furikawari · 12/09/2009, 11h30

Citation:

Envoyé par B.AF

J'ajouterai pour envoyer une soufflante à tous les inutiles que l'informatique est le seul métier du monde où on accepte que des incompétents encadrent.

Petit naïf, c'est faux. C'est pareil partout, ça porte même un nom : le principe d'incompétence maximum. Rapidement, le principe est que les personnes incompétentes, on cherche à s'en débarrasser, et du coup les promotions viennent plus facilement, jusqu'à ce que le système "décide" qu'en grimpant plus haut l'incompétent fera trop de dégats.

batataw · 12/09/2009, 11h46

Citation:

J'aimerai un jour que mon métier ne soit pas le dépotoir du management sous toutes ses formes qui servent de reclassement aux opérationnels qui n'ont pas réussi à s'affirmer et que l'on comprenne aussi que l'efficience d'une équipe n'est pas sa taille mais sa motivation et un niveau de formation constant.

Malheureusement ceci va perdurer pour plusieurs raisons, j'ai travaillé à l'étranger cela m'a permit de prendre un peu de recule par rapport aux méthodes de travail en France:

- La technique est beaucoup trop dépréciée. Elle n'est pas à la place qu'elle devrait être. Elle est considéré comme quelque chose que tout le monde peut apprendre et de toute façon quelque soit le projet on y arrivera.

- Les diplomes ont une importance colossale, un manager sortie d'une grande école aura toujours plus de poids qu'un developpeur expérimenté.

- Nous sommes des latins et nous aimons parler, j'ai assisté à de longues réunions où la moitié des gens ne savaient pas de quoi ils parlaient mais ça sonnait tellement bien à l'oreille que tout le monde était bleuffé sauf l'unique développeur qui par chance a été convié à cette réunion stratégique.

- Une sépération aussi strict de la MOA et la MOE, c'est un non sens total.

A la décharge des managers de tout bord, le personnel dit technique...sont souvent dans l'excès inverse. Si on les laissait faire les projets couteraient 10 fois le prix initiale. Chaque nouvelle version d'une application verrait l'apparition de nouvelles technos. Les directeurs et patrons lassés par un discours techniques imcompréhensibles ont préférés délégués as des subalternes maitrisant le verbe et les chiffres.

Skyounet · 12/09/2009, 13h16

Citation:

Envoyé par Gordon Fowler

2 - Et si vous faisiez réinventer la roue à vos équipes ? : L'open-source c'est le mal. Personne ne peut le nier (cf. point 1). Même pour implémenter des fonctions basiques il est hors de question d'utiliser le "libre". C'est gratuit donc ça tue le business. C'est ouvert donc c'est pas sûr. Et d'ailleurs on ne sait jamais, un jour peut-être faudra-t-il payer des droits sur ces licences bizarres.
Résultat : Une semaine à coder ce que la terre entière a déjà fait mille fois.

Ca vient aussi de la viralité de certaines licences libres. C'est bête de devoir passer toute son application sous GPL pour une petite fonction trouvée sur Internet qui est sous GPL.

el_slapper · 12/09/2009, 13h20

Citation:

Envoyé par g0up1l

4 - ne lis pas les specs ! Inutiles et dangereuses, elles ne font qu'alourdir la charge de travail !

...pour celle-là, ça m'est arrivé. noooon pas la têêêêête, aïeuh!!!

ypicot · 13/09/2009, 09h01

Citation:

Envoyé par B.AF

(qui n'a pas entendu l'expert fonctionnel dire "hors de question que je développe des tests, je ne suis pas technicien!")

Déjà entendu. Et ma réponse "chic, on va pouvoir développer n'importe quoi" a jeté comme un froid, surtout quand j'ai expliqué pourquoi.

Yvan

B.AF · 13/09/2009, 21h29

Ah oui, je connais le principe de peter. Mais j'ose espérer que cela va changer.

_skip · 14/09/2009, 09h00

L'application que je reprend actuellement a été développée par un docteur sur-intelligent (mon chef), malheureusement il connaît de l'informatique ce qu'il a appris à l'université.
En gros son design de base de données est une catastrophe, le code est du spaghetti rempli de :

Code :

try
{
  //100 lignes
}
catch(Exception )
{
   return false;
}

Sans aucune libération des ressources femeture des fichiers etc... en cas d'erreur, une seule connexion permanente à la BDD dans tout le serveur partagée pour tous les clients, et toutes les méthodes en synchronized.

Vous ajoutez à cela des noms de classes à la con, aucune documentation hors code, un fouillis de fichiers de configuration, des cross references entre des bouts de libs qui ne peuvent être compilées que s'il existe une ancienne version du JAR du produit lié. En gros une véritable encyclopédie de ce qu'il faut surtout jamais faire!!!

J'essaie de dire avec tact que c'est du travail de cochon puis que si la moindre chose ne se passe pas comme prévu ou qu'on manque de bol avec une micro-erreur, y'a aucun filet et l'applic se torche salement sans qu'on puisse deviner pourquoi. Il me répond que ça tourne, ça marche, donc on touche pas!

Le parseur XML qui traite les fichiers fournis chaque jour par nos clients est lu à l'aide d'un code barbare qui parse du string sans passer par SAX, ni DOM ni quoi que ce soit. Résultat je me suis aperçu que les fichiers fournis par certains clients étaient mal formés, pourtant ils sont tolérés par l'implémentation barbare, du coup plus possible de changer pour utiliser une lib standard...

Mieux, on continue de développer des nouvelles fonctionnalités par dessus cette base de compost, jusqu'au jour où ça va sérieusement nous exploser à la gueule.

Donc conclusion : les docteurs sont bien dans les labos à inventer des trucs géniaux et super intelligents comme eux, ensuite il faut qu'ils laissent la création des logiciels d'entreprise à des gens comme nous.

Furikawari · 14/09/2009, 09h20

Citation:

Envoyé par _skip

Donc conclusion : les docteurs sont bien dans les labos à inventer des trucs géniaux et super intelligents comme eux, ensuite il faut qu'ils laissent la création des logiciels d'entreprise à des gens comme nous.

Avant de dire des âneries comme celle-ci, tu devrais te demander combien il y a de docteur qui sont développeurs... Mais bon, vus les propos que tu tiens je ne me considère certainement pas comme "quelqu'un comme toi"...

_skip · 14/09/2009, 09h35

Citation:

Envoyé par Furikawari

Avant de dire des âneries comme celle-ci, tu devrais te demander combien il y a de docteur qui sont développeurs... Mais bon, vus les propos que tu tiens je ne me considère certainement pas comme "quelqu'un comme toi"...

Ben oui tu as bien compris, c'est ce que je pense : chacun son métier. Ca te choque?

EDIT: Je parle pas d'un docteur dans le domaine de la santé si jamais.

Furikawari · 14/09/2009, 09h43

Citation:

Envoyé par _skip

Ben oui tu as bien compris, c'est ce que je pense : chacun son métier. Ca te choque?

EDIT: Je parle pas d'un docteur dans le domaine de la santé si jamais.

Je suis docteur (pas dans le domaine de la santé...) et je suis plutôt bien vu par les développeurs avec qui j'ai bossé. De même qu'un des meilleurs développeurs que j'ai pu rencontrer, qui est également docteur. A partir d'un certain niveau intellectuel, il est bon de savoir s'affranchir des préjugés.

Soit dit en passant, en ce moment je bosse sur un code de m**** développé par un ingénieur informaticien, un vrai. Chacun son métier comme tu dis...

11/09/2009, 12h20	#1
Gordon Fowler Responsable Actualités Date d'inscription: juillet 2009 Messages: 907	Avez-vous déjà été énervé par un "responsable irresponsable" dans votre carrière de développeur ? Avez-vous déjà été énervé par un "responsable irresponsable" dans votre carrière de développeur ? Comme partout, il y en a des bons. Mais aussi des mauvais. Il y a des sympas. Mais certains sont de vrais tyrans. Il y en a des compétents. Mais il y a aussi les incapables. Loin de nous, donc, l'idée de jeter l'opprobre sur les responsables de projets logiciels. Et encore moins de dresser le portrait d'une profession sans laquelle rien ne pourrait se faire ! Mais il faut bien admettre que beaucoup parmi ceux qui ne développent plus (... qui n'ont jamais développé ?), ont quelques travers particulièrement énervants... dont on peut se demander d'ailleurs s'ils ne sont pas catalogués dans un manuel du parfait "irresponsable" de projet : 1 - N'oubliez pas ! Vous savez tout mieux que tout le monde : donc c'est à vous de décider. Ne posez pas de cadre au développement, de cette manière vous pourrez rajouter en continu (et jusqu'au jour de livraison du programme !) les fonctionnalités supplémentaires que le client vous demande. Ne les discutez pas et ne prenez surtout pas en compte la road-map (ça pourrait le fâcher). Résultat pour vous : un code qui ressemble à un plat de spaghetti truffé de bugs et des heures supplémentaires pour tenir les délais. 2 - Et si vous faisiez réinventer la roue à vos équipes ? : L'open-source c'est le mal. Personne ne peut le nier (cf. point 1). Même pour implémenter des fonctions basiques il est hors de question d'utiliser le "libre". C'est gratuit donc ça tue le business. C'est ouvert donc c'est pas sûr. Et d'ailleurs on ne sait jamais, un jour peut-être faudra-t-il payer des droits sur ces licences bizarres. Résultat : Une semaine à coder ce que la terre entière a déjà fait mille fois. 3 - L'outil ne fait pas le travailleur, il n'y a aucune raison que les développeurs choisissent : Le développeur ne doit être impliqué que dans ce qui le concerne (choix de la couleur du clavier, marque de l'écran, etc.). Le bon manager impose framework, langage, et tout ce genre de chose (cf. point 1). Résultat : Le confort de travail en prend un coup. Ce qui demanderait 3 jours de travail effectif peut prendre jusqu'à deux siècles. 4 - Une équipe qui tourne est toujours louche : Il y a souvent anguille sous roche. Dans ce cas, imposer une réunion pour tirer l'affaire au claire. Si vous ne trouvez rien, n'hésitez pas à en faire une bonne centaine. Vous verrez qu'en cherchant bien, ces équipes ne travaillaient pas selon le process décrit page 27 de l'annexe F du deuxième rapport de la Version 2.7.3.a du Manifeste Agile de votre société. Vous le saviez ! (cf. point 1) Résultat : plus aucun résultat, l'équipe est en réunion. 5 - Ne passez pas mille ans à tester : Tester c'est de l'argent perdu. Ce qui est fait est fait. Vendez plutôt ! Si le produit ne fonctionne pas mettez le sur le dos du développeur, c'est lui le responsable des bugs non? Dîtes bien au client qu'une mise à jour est en cours et n'oubliez pas de passer un savon au développeur. Il se doit d'être à votre niveau d'excellence (cf. point 1). Résultat : La qualité logicielle est proche de zéro et on vous accuse de mal faire votre boulot. Soyons honnête, les responsables de projet ne sont pas comme ça. Mais il vous est certainement arrivé d'en croiser au moins un qui a appliqué ces commandements... Pas vrai ? Et vous ? Lequel de ces travers de responsable avez-vous croisés le plus souvent ? Dîtes nous ce qui vous a le plus énervé dans votre carrière de la part d'un "responsable irresponsable" ? Lire aussi : Les 10 phrases qui rendent fou un informaticien : les avez-vous déjà entendues ?

11/09/2009, 14h49	#2
g0up1l Membre éclairé Date d'inscription: janvier 2006 Localisation: Du côté de chez Rabelais Messages: 326	très bonnes remarques ! Maintenant, on peut aussi être énervé en tant que chef d'équipe par un développeur irresponsable ! En voici un manuel : 1 - ne perd pas de temps à sauvegarder tes sources ! C'est du temps de perdu et de toute façon tu as tout dans la tête ! 2 - ne prend pas la peine de vérifier le numéro de la version que tu dois faire évoluer, ton chef n'avait qu'à te le dire ! 3 - ne prend pas la peine de tester ce que tu livres, il sera toujours temps d'évoquer une maladresse involontaire ! 4 - ne lis pas les specs ! Inutiles et dangereuses, elles ne font qu'alourdir la charge de travail ! 5 - et surtout, ne rédige aucune doc ! L'utilisateur est un veau incapable de comprendre l'intuitivité de ta merveilleuse application __________________ Hope it helps ! Nouveau ! Il y a une vie après le java, oxygénez-vous

14/09/2009, 09h00	#17
_skip Membre Expert Date d'inscription: novembre 2005 Localisation: Suisse Âge: 26 Messages: 1 458	L'application que je reprend actuellement a été développée par un docteur sur-intelligent (mon chef), malheureusement il connaît de l'informatique ce qu'il a appris à l'université. En gros son design de base de données est une catastrophe, le code est du spaghetti rempli de : Code : try { //100 lignes } catch(Exception ) { return false; } Sans aucune libération des ressources femeture des fichiers etc... en cas d'erreur, une seule connexion permanente à la BDD dans tout le serveur partagée pour tous les clients, et toutes les méthodes en synchronized. Vous ajoutez à cela des noms de classes à la con, aucune documentation hors code, un fouillis de fichiers de configuration, des cross references entre des bouts de libs qui ne peuvent être compilées que s'il existe une ancienne version du JAR du produit lié. En gros une véritable encyclopédie de ce qu'il faut surtout jamais faire!!! J'essaie de dire avec tact que c'est du travail de cochon puis que si la moindre chose ne se passe pas comme prévu ou qu'on manque de bol avec une micro-erreur, y'a aucun filet et l'applic se torche salement sans qu'on puisse deviner pourquoi. Il me répond que ça tourne, ça marche, donc on touche pas! Le parseur XML qui traite les fichiers fournis chaque jour par nos clients est lu à l'aide d'un code barbare qui parse du string sans passer par SAX, ni DOM ni quoi que ce soit. Résultat je me suis aperçu que les fichiers fournis par certains clients étaient mal formés, pourtant ils sont tolérés par l'implémentation barbare, du coup plus possible de changer pour utiliser une lib standard... Mieux, on continue de développer des nouvelles fonctionnalités par dessus cette base de compost, jusqu'au jour où ça va sérieusement nous exploser à la gueule. Donc conclusion : les docteurs sont bien dans les labos à inventer des trucs géniaux et super intelligents comme eux, ensuite il faut qu'ils laissent la création des logiciels d'entreprise à des gens comme nous.

11/09/2009, 14h50	#3
B.AF Membre émérite Date d'inscription: février 2005 Messages: 734	Personnellement, j'ai l'erreur #5 à mon passif.

11/09/2009, 18h05	#7
palnap Membre à l'essai Date d'inscription: novembre 2006 Messages: 46	Moi j'ai un peu de mal avec les responsables de projets qui n'ont jamais codé (oui, une analyse UML présentant le cas idéal ça fait pas tout) ou pas dans un gros projet :/ Ou qui considèrent jamais les spécificités d'un projet informatique (ben t'es pas capable de quantifier ton travail avant de définir les technos utilisées ?) J'aurai rajouté celle-là : "n'oubliez pas de toujours plus en demander à vos salariés, s'ils sont capables de multiplier leur productivité par 4 pendant 15 jours en fin de projet, pourquoi pas éternellement ?"

12/09/2009, 10h32	#10
B.AF Membre émérite Date d'inscription: février 2005 Messages: 734	J'ajouterai pour envoyer une soufflante à tous les inutiles que l'informatique est le seul métier du monde où on accepte que des incompétents encadrent. C'est terrifiant. Pourquoi ? De un, beaucoup ne savent pas quoi attendre du développement. Ce que j'appelle la "ruralité" de l'IT. Et c'est déjà le début des conflits Cela améne à des gestion de la qualité qui coutent beaucoup et passent souvent à la trappe (qui n'a pas entendu l'expert fonctionnel dire "hors de question que je développe des tests, je ne suis pas technicien!") Il serait temps que les informaticiens se ré-approprient leur métier, et que les RH arrêtent cette politique stupide de croire qu'une personne avec un background de manager opérationnel peut encadrer des projets techniques ! Une fois de plus, ce dysfonctionnement n'existe que dans l'informatique. Dans un laboratoire pharmaceutique, les chefs de projet n'ont pas fait des sup de co, dans l'aéronautique, les chefs de projet n'ont pas fait un dess gestion des SI ou autre. J'aimerai un jour que mon métier ne soit pas le dépotoir du management sous toutes ses formes qui servent de reclassement aux opérationnels qui n'ont pas réussi à s'affirmer et que l'on comprenne aussi que l'efficience d'une équipe n'est pas sa taille mais sa motivation et un niveau de formation constant. Bref, un métier à révolutionner :

13/09/2009, 21h29	#16
B.AF Membre émérite Date d'inscription: février 2005 Messages: 734	Ah oui, je connais le principe de peter. Mais j'ose espérer que cela va changer.

		Forum des professionnels en informatique > Le club des professionnels en informatique > Actualités
Avez-vous déjà été énervé par un "responsable irresponsable" dans votre carrière de développeur ?

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email