Les petits mensonges des programmeurs dévoilés

@Kilimandjaro

Je suis assez d'accord avec vous en dehors du point 8 : ayant d'abord été développeur, mais faisant de l'infra depuis plusieurs années, je suis souvent exaspéré par les codeurs qui n'optimisent pas leurs applications, demandent des niveaux de droits inappropriés et exigent des équipes systèmes qu'elles se débrouillent pour pallier les lenteurs de leurs programmes avec des machines surdimensionnées.

Mais cela revient toujours au même problème : leur laisse-t-on le temps de le faire et les forme-t-on correctement sur ces enjeux ?

1 / Le code est auto-documenté. Inutile de rédiger une documentation à part.

Ok pour l'idée, mais quel employeur laisse à ses dévs tout le temps nécessaire pour documenter correctement leur travail ?

2 / C'est un problème de base de données ou de matériel, pas un problème de programmation.

Le coup de l'ignorance d'autrui peut marcher si vous êtes seul, mais en groupe, vous serez vite repérés !

Cela étant, l'inverse est vrai aussi : quand quelque chose ne marche pas, c'est forcément la faute de l'informaticien ou de l'informatique, jamais de l'usager lui-même.

3 / Ce n'est pas un bug. C'est l'utilisateur qui fait quelque chose qu'il ne devrait pas faire.

Est-ce faut d'affirmer que les usagers font bien souvent n'importe quoi ? Cela étant, un bon programme est censé vérifier ses saisies et faire le tri. Là encore, en groupe, vous serez vite repérés si vous jouez à ce jeu là.

4 / Je suis le seul qui sait ce que fait ce programme, ils ne pourront jamais me virer.

Il ne faut pas se voiler la face : le pouvoir du développeur est une réalité. Donner les clés du S.I., c'est donner quelque part les clés de la société ! Maintenant entre l'abus de pouvoir de l'employé, qui peut être tenté de se croire indispensable, et la paranoïa aigüe de l'employeur, qui ne peut pas tout contrôler et comprendre, la relation de confiance est une condition indispensable entre les parties !

Le "ils ne pourront jamais me virer" me paraît quand même un petit peu gros, parce que même s'il connaît son "pouvoir" tout relatif, je ne pense pas qu'un développeur soit assez con pour en abuser. Je prendrais plus ce type de signal comme une demande d'augmentation cachée, que comme une confrontation directe à l'autorité.

5 / Je sais ce que le client veut. Je sais ce que le client a dit, mais ce n'est pas réellement ce qu'il veut.

Toute boîte de développement connaît ce type de problème, qui part le plus souvent d'un excès d'enthousiasme du développeur, et non d'une volonté de nuire ou d'imposer sa vision à tout prix !

Il faut simplement rappeler qui paie, et remettre calmement les choses à leur place. En général, ça se passe très bien, chez certains mieux que chez d'autres !

6 / La partie Questions/Réponses permettra de trouver tous les bugs. Il n'est pas nécessaire de se laisser submerger par les tests maintenant.

S'il est clair qu'en extreme programming, le test est obligatoire, en programmation plus "classique", il n'est pas toujours évident non plus de placer des tests à tout va, sans compter que cela n'assure pas le 0 défaut au final : cela permet juste de régler certains problèmes découverts dans la phase de développement.

7 / Ce correctif est tellement simple que l'on peut le mettre directement en production.

La tentation est toujours grande de vouloir sauter les étapes, mais il est clair que sur un gros projet, c'est du suicide à coup sûr. Dans une petite structure en revanche, je pense que ce comportement n'est pas forcément un manque de volonté du développeur, mais bien souvent un manque de temps.

8 / Bien sûr, on peut monter en charge. Dans le pire des cas, nous mettrons un serveur supplémentaire pour équilibrer la charge.

Est-ce bien au développeur de s'occuper de l'administration système ?

9 / Je pourrais réécrire ce vieux programme, qui ressemble à un plat de spaghettis, et économiser du temps sur le long terme.

Sur ce point là, je suis plutôt d'accord, et pour une raison très simple : traîner des casseroles vous empêche d'avancer correctement. Les langages évoluent, et c'est tout à fait normal. Le développeur suit cette progression naturelle, et va forcément gagner du temps en utilisant de nouvelles manières de faire.

Le vrai problème de base est que les donneurs d'ordre ont (beaucoup) de mal à comprendre qu'un logiciel demande un suivi régulier, d'où le rôle indispensable du commercial.

10 / Quand je joue sur internet, je pense à la programmation, dès lors c'est comme si je programmais.

Si par jeu, vous entendez la veille technologique indispensable au développeur, alors quelque part, j'ai envie de dire que l'affirmation n'est pas fausse en soi. Si le développeur tombe sur un tutorial ou un article technique intéressant, qui peut l'aider à s'améliorer, et à augmenter sa productivité, je ne vois pas où est le problème.

Quand à celui qui abuse du net, il est en général rapidement repéré et recadré. On ne paie pas les gens pour voir des films au boulot - faut pas déconner non plus...