Discussion :

[Jannus]

C'est trop drôle... Le "bidouilleur" fait ceci, Le "Pro" fait cela...
Autant dire que Le français mange de la baguette et boit du vin et que Le belge mange des frites et boit de la bière.

J'ai connu des "Pro" (entk des personnes munies d'un diplôme universitaire "informatique-programmation") incapables de mettre un projet sur pied et des "bidouilleurs" qui leur en mettaient plein la vue avec des logiciels non seulement parfaitement écrits, clairs, simples et sécurisés, mais encore capable d'effectuer des tâches que les "Pro" ne pensaient pas réalisables.

[Baptiste Wicht]

C'est trop drôle... Le "bidouilleur" fait ceci, Le "Pro" fait cela...
Autant dire que Le français mange de la baguette et boit du vin et que Le belge mange des frites et boit de la bière.

J'ai connu des "Pro" (entk des personnes munies d'un diplôme universitaire "informatique-programmation") incapables de mettre un projet sur pied et des "bidouilleurs" qui leur en mettaient plein la vue avec des logiciels non seulement parfaitement écrits, clairs, simples et sécurisés, mais encore capable d'effectuer des tâches que les "Pro" ne pensaient pas réalisables.

Quelle est la différence pour toi entre un bidouilleur et un pro, parce que ne je pense pas qu'un bidouilleur fasse un code comme tu le décris, mais par contre, je suis d'accord avec le fait qu'un programme écrit par un bidouilleur puisse être tout à fait fonctionnel.

[Christianchristian]

Bonjour,

Je pense quei la bidouille est avant tout un état d'esprit qui caractérise le bidouilleur aussi bien dans l'étude et la réalisation d'applications l'informatiques que dans les actions de la vie courante.

Ce qui, en totalité (ce n'est pas souhaitable) ou en partie, caractérise bien souvent ce profil :

_ Manque de rigueur. (finalise rarement ses actions)
_ Manque d'humilité (prétend tout savoir, est encré dans ses certitudes.)
_ Solde les problèmes par un : "Pas d'problème", "Y'a qu'à", "Faut qu'on"
rarement suivis de résultats.
_ Privilégie la terminologie et la mode (informatiques) du jour au détriment
du savoir-faire.
_ Privilégie le : "Pourquoi faire simple quand on peu faire compliqué". Bien
souvent à des fins de valorisation.
_ Est particulièrement inefficace et ne semble pas devoir tirer un
quelconque enseignement de ses échecs (suffisance).
_ Connait dans les grandes lignes un peu de tout au point qu'il prétend
tout maîtriser.
_ A une fâcheuse tendance à cambrioler les autres en s'appropriant leurs
idées.

_ Attache finalement peu d'importance à la réalisation pour peu qu'elle soit
traditionnelle. Préfére la pratique de l'informatique dite (par
dérision) expérimentale.
_.............................

Pro :
_ Remise en question permanente, non pas en terme de faisabilité mais
en terme de recherche de qualité. (S'intéresse en premier lieu
aux besoins de l'utilisateur final, ...............)
_ Ne pratique pas la rétention d'informations.
_ Utilise l'informatique à des fins professionnels et non pas essentiellement
pour justifier d'un status "socio-professionnel" valorisant ou
considéré comme tel.
_ .......................
Je ne suis pas tendre avec le profil du bidouilleur, qu'il soit informaticien ou non, en regard des dégats occasionnés au fil du temps à l'informatique par ce comportement.
Une des conséquences de ce comportement s'illlustre par le relatif clivage (il tend à s'amenuiser) existant entre l'informatique dite "Grand système" et celle dite "Micro".
Mais c'est un autre débat!

[Jannus]

Quelle est la différence pour toi entre un bidouilleur et un pro

Je désirais simplement exprimer mon étonnement devant ces assertions : "le bidouilleur ceci", "le pro cela" et faire gentiment remarquer que tout amalgame est une erreur (sauf chez les dentistes ) et qu'il y a du bon et du mauvais partout

Cela dit, et pour te répondre, je me considère comme un "bidouilleur" parce que je suis auto-didacte et que je suis loin de suivre les sacro-saintes méthodes enseignées dans les écoles. Cela ne m'a pas empêché de faire des logiciels d'excellente qualité (ce n'est pas seulement mon avis, mais aussi celui des centaines de clients qui les ont utilisés).

Évidemment, si je me réfère au message ci-dessus, je suis bien obligé d'admettre que le profil du "bidouilleur" ne me convient guère.

[Eusebius]

Je désirais simplement exprimer mon étonnement devant ces assertions : "le bidouilleur ceci", "le pro cela" et faire gentiment remarquer que tout amalgame est une erreur (sauf chez les dentistes ) et qu'il y a du bon et du mauvais partout

Je pense justement que le sujet du topic n'était pas d'accoler des comportements-types à des "bidouilleurs" ou des "pros" déjà définis par ailleurs, mais justement de les définir. J'imagine que tout le monde ici est d'accord pour dire que sortir de telle école ou bosser comme développeur n'est pas suffisant pour éviter d'être un bidouilleur

[Christianchristian]

Évidemment, si je me réfère au message ci-dessus, je suis bien obligé d'admettre que le profil du "bidouilleur" ne me convient guère. [/quote]

Bonsoir,

Je ne comprends pas l'amalgame autodidacte

[Christianchristian]

Évidemment, si je me réfère au message ci-dessus, je suis bien obligé d'admettre que le profil du "bidouilleur" ne me convient guère.

Bonsoir,

Je ne comprends pas l'amalgame autodidacte - bidouilleur que vous semblez devoir faire.
Je suis moi-même autodidacte et je me suis efforçé durant près de 20 années d'études/développement de ne pas bidouiller.


Cordialement.

[GrandFather]

On peut assez facilement recenser les comportements associés à la bidouille ou à une approche professionnelle du développement, mais s'il s'agit de déterminer si un développeur a une tendance dominante parmi ces deux stéréotypes, c'est une toute autre affaire...

Quel "pro", poussé par les délais, n'a pas contourné un bug vicieux dans son appli par une vilaine bidouille, en se promettant de le corriger ultérieurement dès qu'il aurait un peu de temps une fois l'appli en prod ? Souhait le plus souvent non réalisé, le temps continuant à faire défaut...

A l'inverse, le "bidouilleur", s'il est doué et passionné, va progressivement réinventer empiriquement les bonnes pratiques de développement des "pro". Mais ses débuts seront souvent difficiles voire épouvantables, et il n'y arrivera qu'au prix d'énormément d'efforts. Les autodidactes (dont je suis) ont plutôt ce profil.

[Hephaistos007]

On peut assez facilement recenser les comportements associés à la bidouille ou à une approche professionnelle du développement, mais s'il s'agit de déterminer si un développeur a une tendance dominante parmi ces deux stéréotypes, c'est une toute autre affaire...

Quel "pro", poussé par les délais, n'a pas contourné un bug vicieux dans son appli par une vilaine bidouille, en se promettant de le corriger ultérieurement dès qu'il aurait un peu de temps une fois l'appli en prod ? Souhait le plus souvent non réalisé, le temps continuant à faire défaut...

A l'inverse, le "bidouilleur", s'il est doué et passionné, va progressivement réinventer empiriquement les bonnes pratiques de développement des "pro". Mais ses débuts seront souvent difficiles voire épouvantables, et il n'y arrivera qu'au prix d'énormément d'efforts. Les autodidactes (dont je suis) ont plutôt ce profil.

+1000. Tu as bien résumé mon point de vue sur ce sujet à caractère trollistique.

[davcha]

Il serait sûrement plus intéressant de discuter des bonnes pratiques de développement (pratiques aussi bien générales que un peu plus spécifiques), non ?

[Christianchristian]

[quote=GrandFather]

Quel "pro", poussé par les délais, n'a pas contourné un bug vicieux dans son appli par une vilaine bidouille, en se promettant de le corriger ultérieurement dès qu'il aurait un peu de temps une fois l'appli en prod ? Souhait le plus souvent non réalisé, le temps continuant à faire défaut...

Bonjour,

Vous touchez là un point sensible. Votre exemple et la situation, effectivement réaliste, qu'il sous-entend doivent je pense permettre de mieux illustrer le problème posé.

Ne pensez-vous pas que dans une telle situation, il existe au moins deux types d'attitudes ?
L'une d'elles consite à :
1) Commenter la (ou les) partie(s) du code (du ou des pgm) concernés. (c-a-d celle(s) suspectée(s) d'être à l'origine du bug en question)
2) Informer sa hiérarchie du problème et de la nécessité, à terme, de dégager du temps afin d'y remédier. Cela peut entraîner une modification du planning. (Il n'est pas rare de devoir argumenter et défendre sa position dans ce genre de situation, généralement peu confortable.)
3) Informer ou ne pas informer, en accord avec la hiérarchie, l'utilisateur (les utilisateurs) des éventuelles pénalités ou carences relatives à ce bug.
4) Mettre, ou ne pas mettre, en exploitation à la date prévue, suivant les réactions du ou des utilisateurs (Décision de la ou des directions du ou des services concernés).


L'autre attitude consiste à faire l'impasse ..........
En gardant à l'esprit que le problème en question ressurgira avec d'autant plus d'acuité que le moment sera certainement inopportun. En se souvenant aussi que des données pourront être définitivement perdues. De plus Il n'est pas rare qu'une erreur en cache une autre.
J'ai vu, à plusieurs reprises des collégues noyés sous les problèmes suite à des mises en exploitation prématurées.
Le rapport de temps mis à réparer le bug et à "remettre des béquilles" à l'appli est de l'odre de 1 sur 5 si ce n'est davantage dans certains cas.


Une troisème attitude plus dangereuse et qui en terme de faisabilité dépend du probléme, consiste elle aussi, à faire l'impasse mais en parfaite connaissance de cause. Par exemple en évaluant les pénalités et le moment où elles se présenteront effectivement à l'utilisateur (si ces pénalités ne sont pas immédiates) et les solutions à mettre en oeuvre pour y remédier. (par exemple : recalage à terme de fichiers après correction du bug ayant entraîné une perte ou une altération de certaines données. Après avoir déterminé si celles-ci pouvaient être reconstituées et dans quelles conditions). Mais cette troisième attitude s'emble se fondre dans les propositions 1) , 2) et peut-être 3) de la première attitude.

C'est un peu long, j'en conviens.

En résumé je ne ferai aucun résumé. Je laisse le soin aux personnes qui ont bien voulu lire ce texte de faire un choix ou si elles estimes que je me trompe de bien vouloir me contredire.

Cordialement,

[GrandFather]

2) Informer sa hiérarchie du problème et de la nécessité, à terme, de dégager du temps afin d'y remédier. Cela peut entraîner une modification du planning. (Il n'est pas rare de devoir argumenter et défendre sa position dans ce genre de situation, généralement peu confortable.)
3) Informer ou ne pas informer, en accord avec la hiérarchie, l'utilisateur (les utilisateurs) des éventuelles pénalités ou carences relatives à ce bug.
4) Mettre, ou ne pas mettre, en exploitation à la date prévue, suivant les réactions du ou des utilisateurs (Décision de la ou des directions du ou des services concernés).

C'est effectivement l'attitude responsable à adopter, quand le risque de rupture de service ou de perte d'exploitation pour l'entreprise est clairement identifié. Mais quand il s'agit de problèmes spécifiques au développement et qui n'ont pas de répercussions négatives visibles et immédiates pour les utilisateurs ou la MOA, c'est une autre paire de manches... Comment justifier auprès de sa hiérarchie des délais supplémentaires pour corriger des problèmes non liés au fonctionnel de l'application, mais empêchant par exemple d'adopter la conception modulaire prévue lors de l'analyse, en vue d'éventuelles évolutions à venir ? Le problème est tellement ésotérique pour un non informaticien qu'il lui est difficile de se prononcer, s'il ne lui vient pas en plus à l'esprit le soupçon qu'il s'agit d'une manoeuvre dilatoire... Alors, plutôt que d'affronter cela, le développeur, discrètement, fait cela à sa sauce, et on retombe dans le comportement que j'ai décrit. Cette situation je l'ai vécue au sein d'un SI, et je pense que la situation ne doit être guère différente en SSII.

Une troisème attitude plus dangereuse et qui en terme de faisabilité dépend du probléme, consiste elle aussi, à faire l'impasse mais en parfaite connaissance de cause.

Là, on ne parle plus de bidouille, on est plus proche de la faute professionnelle.

[davcha]

Comment justifier auprès de sa hiérarchie des délais supplémentaires pour corriger des problèmes non liés au fonctionnel de l'application, mais empêchant par exemple d'adopter la conception modulaire prévue lors de l'analyse, en vue d'éventuelles évolutions à venir ?
[...]
le développeur, discrètement, fait cela à sa sauce, et on retombe dans le comportement que j'ai décrit.

Donc pour garder une bonne cohérence du projet, on fait des acrobaties qui au final plombent la cohérence du projet ?

[GrandFather]

Donc pour garder une bonne cohérence du projet, on fait des acrobaties qui au final plombent la cohérence du projet ?

D'une certaine manière, oui. Mais qui a dit que nous vivions dans un monde parfait ?

[nikalkal]

Salut,

pour moi la différence entre un pro et un bidouilleur c'est qu'un pro qui à un projet à réaliser de A à Z fera 80% de son travail sans tenir compte de la technologie finale qui sera utilisé pour coder.

[Christianchristian]

Bonjour,

La situation n’est guère confortable, comme cela a été évoqué mais la réponse de davcha me semble résumer tout le problème. Car enfin laisser délibérément un problème recensé en suspend, que celui-ci intéresse ou non le fonctionnel, me semble participer de la politique du « jusque là ça va ». Notre métier ne consiste-t-il pas aussi à anticiper ? Quelle sera l’attitude face à sa hiérarchie du développeur ayant fait l’impasse le jour où le problème ressurgira ? Comment pourra-t-il justifier cette attitude ?
On peut imaginer le dialogue hiérarchie/développeur : (que la hiérarchie soit sincère ou non ne change rien au problème)
_ Pourquoi n’avez-vous rien dit ?
_ J’étais surchargé de travail
_ Pourquoi ne pas avoir demandé de l’aide ?
]............................
Mais ne s’agit-il pas aussi et surtout de préserver l’intégrité et par là de défendre sa profession ?
Vous évoquez la faute professionnelle à propos de l’attitude n° 3, il me semble que ne rien dire d’un problème connu susceptible d’engendrer des pénalités à une communauté s’apparente davantage à la faute professionnelle que prendre même les risques calculés énoncés dans cette attitude n° 3.

Au moment où j’écris ce texte je prends connaissance de votre dernier message (réponse à davcha). Là je m’incline !

Cordialement.

[GrandFather]

Quelle sera l’attitude face à sa hiérarchie du développeur ayant fait l’impasse le jour où le problème ressurgira ? Comment pourra-t-il justifier cette attitude ?
On peut imaginer le dialogue hiérarchie/développeur : (que la hiérarchie soit sincère ou non ne change rien au problème)

On ne doit pas avoir la même hiérarchie... Un dialogue, réel celui-là, que j'ai eu avec la mienne il y a une quinzaine de jours illustre la difficulté de ce genre de dialogue. Je dresse le tableau : après avoir constaté la présence d'un bug mineur dans une application la veille de sa mise en production, je demande après analyse à un programmeur de mon équipe de le corriger, ce qui est fait sans que la mise en production soit reculée. J'en informe ma directrice lors d'un point hebdomadaire :

Elle : combien de temps ça lui a pris ?
Moi : environ une heure.
Elle : Quoi, une heure !? Mais c'était un problème absolument minime, qui a peu de chances de se reproduire ! Il aurait pu la consacrer à autre chose.
Moi : Il était hors de question de laisser un problème identifié dans une application, on le corrige et on en parle plus ! De plus, rien ne garantit que les circonstances dans lesquelles il se produit ne se représenteront pas.
Elle : De toute façon, vous êtes un perfectionniste...

Le reste du "dialogue" débouche sur un statu quo, elle reste persuadée, n'y connaissant rien, que nous nous montrons pointilleux pour augmenter notre importance, et de mon côté je refuse à ce qu'un néophyte me dicte comment faire mon travail... Est-elle particulièrement obtuse ? Peut-être. Mais je suis sûr par contre qu'elle n'est pas une exception, et que cette incompréhension et cette approche irrationnelle du développement informatique est partagée par beaucoup de cadres dirigeants. Alors quand il va falloir que je lui explique qu'il faut que l'on obtienne du temps supplémentaire parce qu'il faut pour un projet "procéder à la correction du framework MVC du fait que la prise en charge de notre SGBD par des objets DAO de ce framework révèle des dysfonctionnements", j'ai intérêt à m'accrocher...

Vous évoquez la faute professionnelle à propos de l’attitude n° 3, il me semble que ne rien dire d’un problème connu susceptible d’engendrer des pénalités à une communauté s’apparente davantage à la faute professionnelle que prendre même les risques calculés énoncés dans cette attitude n° 3.

Là je ne suis absolument pas d'accord, les deux situations n'ont rien de comparable dans leurs implications. Si déjà nous, développeurs, n'avons pas été capables d'anticiper et de venir à bout d'une difficulté mineure intervenue lors du développement, qu'en sera-t-il de celles qui se présenteront lorsqu'il faudra faire une reprise sur incident et restituer l'intégrité d'une base de données corrompue, avec la pression qu'on imagine ? Mettre en danger l'activité d'une entreprise au nom d'un orgueil professionnel ne me semble pas très judicieux...

[davcha]

Est-elle particulièrement obtuse ?

Oui
Enfin, c'est juste un avis personnel vis à vis de ce que tu viens de raconter, évidemment.

Y'a pas si longtemps, j'ai eu une petite discussion avec un client, lui expliquant, grosso modo, que j'allais devoir repenser une bonne partie de l'application et de son fonctionnement, et qu'il était possible que cela allonge mes délais.
Je lui ai expliqué que si on continuait dans la direction qu'on avait prise, le truc risquait d'être bourré de bugs, atroce à maintenir et pas pratique à utiliser pour lui (J'avoue avoir un peu exagéré ).
Toujours est-il qu'il a très vite compris que cette refonte allait lui permettre d'avoir un truc beaucoup mieux, stable et souple.

Enfin, ceci dit, je n'ai pas d'autre hiérarchie que mes clients, moi, donc... J'ai pas de directeur marketing ou autre qui vient m'embêter toutes les 3 heures. C'est pas le même monde.

[Christianchristian]

Bonsoir,

Elle : De toute façon, vous êtes un perfectionniste...
Ce à quoi je ne manquais pas de répondre, lorsque ce reproche imbécile m'était adressé : l'informatique s'accomode mal d'un manque de rigueur.
Si, si j'ai eu la même hiérarchie que vous (mais pas au point quand même de devoir justifier d'une heure de travail).
Ce qui me surprend dans ce dialogue accompagné de vos commentaires c'est que vous semblez défendre, face à votre hiérarchie, une position contradictoire avec votre opinion sur la bidouille. On pourrait presque en dégager l'opinion suivante : si les gens bidouillent (quelquefois) c'est qu'ils sont contraints et forcés par leur hiérarchie. Si tel est le cas je n'ai plus rien à ajouter car nous serions en présence d'un autre problème, bien légitime et particulièrement sensible, celui de la préservation de son poste et de sa carrière au sein de l'entreprise. Et là je me garderais bien de donner mon avis. Pour ma part j'ai parlé d'"état d'esprit" à propos du bidouilleur.
Aussi éloquent que puisse être ce dialogue réel il ne répond pas à la question posée qui peut se résumer par :
Faut-il monter au créneau en temps réel, c'est à dire au moment ou l'événement se produit, ou bien le traiter en différé avec les conséquences que l'on sait ? Dans les deux cas on aura affaire à la hiérarchie.

Quant à votre réponse au sujet de l'attitude n°3, je n'ai pas très bien saisi le sens de votre réponse, je l'ai présentée comme un compromis qui me semble responsable de la part d'un professionnel ayant pris toutes les garanties concernant sa faisabilité. Ce qui m'échappe c'est le sens de votre remarque concernant la mise en péril de la structure. C'est faisable ou pas.
Je ne vois pas bien non plus ce que vient faire l'orgueil professionnel dans ce genre de démarche.

Cordialement,

[GrandFather]

Ce qui me surprend dans ce dialogue accompagné de vos commentaires c'est que vous semblez défendre, face à votre hiérarchie, une position contradictoire avec votre opinion sur la bidouille. On pourrait presque en dégager l'opinion suivante : si les gens bidouillent (quelquefois) c'est qu'ils sont contraints et forcés par leur hiérarchie.

Je n'ai pas expliqué pourquoi les gens bidouillaient, j'ai juste voulu illustrer le fait que dans certaines circonstances l'alternative à la bidouille n'allait pas toujours de soi. Et si j'ai donné l'impression de la cautionner, c'est que je me suis mal exprimé ; la bidouille est un aveu d'échec.

Faut-il monter au créneau en temps réel, c'est à dire au moment ou l'événement se produit, ou bien le traiter en différé avec les conséquences que l'on sait ? Dans les deux cas on aura affaire à la hiérarchie.

Pas nécessairement. Si le problème est réglé par une bidouille, il n'y aura pas d'autre conséquence que l'inconfort moral du développeur qui sait qu'il y a quelque part un truc dans son code dont il n'est pas très fier... On ne devrait monter au créneau que s'il y a véritablement danger pour le projet, à court ou long terme. C'est vraiment une question de degré et de circonstances, je pense.

Quant à votre réponse au sujet de l'attitude n°3, je n'ai pas très bien saisi le sens de votre réponse, je l'ai présentée comme un compromis qui me semble responsable de la part d'un professionnel ayant pris toutes les garanties concernant sa faisabilité. Ce qui m'échappe c'est le sens de votre remarque concernant la mise en péril de la structure. C'est faisable ou pas.

Avant de se retrouver face à un problème qui dans l'état actuel de ses connaissances ne peut pas être résolu mais juste contourné, ce même professionnel avait aussi considéré que cela était faisable... Il y a dans notre métier un tabou à parler de la part d'aléa et de contingences qui font que certains problèmes ne peuvent être facilement anticipés. Les méthodes de génie logiciel, l'utilisation de librairies éprouvées, une conception rigoureuse, l'expérience, etc. réduisent le facteur risque, mais ne l'annulent pas. Donc, je ne prendrai jamais le risque de dire : "Si ça plante plus tard, c'est pas grave, on corrigera les données". Ce serait faire la présomption qu'on pourra pourvoir à toutes les situations, alors que - je le rappelle - tout cela part d'un problème imprévu pour lequel on ne voit pas de solution "académique" immédiate. On demande dans ce cas un délai supplémentaire pour corriger le problème, ou on le contourne, mais cette troisième voie me semble à exclure du fait des risques qu'elle fait encourir.