Et oui. Bon nombre de manager n'integre tout simplement pas la notion de bug. Ils se disent qu'il devraient imputé une certaine somme sur le salaire du gars qui a écrit un bug, comme ça la prochaine fois il recommencera pas, le salaud.
Savent pas qu'un bug peut être conceptuel, ie, pas de bug de codage mais que l'archi en elle meme puisse etre vereuse, et qu'il faille tout changer.
sans savoir qu'il y a une contradiction forte entre la "productivité" (bien souvent résumé au nombre de ligne de code écrite, ou, parfois, au nombre de bugs résolu ou de feature développé/semaine) et "qualité". Les deux partages la même quantité de ressource (le cerveau de l'ingé), donc on peut pas tirer sur l'un sans diminuer 'autre.
Et il savent ce que sont les maths, c'est pas dûr je te dis :
- un ingé de base corrige 1 bug/jour
- deux ingé corrigeront 2 bug/jour
...
Ca lui viendrait pas à l'esprit qu'un bug mal corrigé puisse en générer 15.
si 2 ingé sur le même poste n'écrivent qu'1 feature/jour (ou corrige qu'1 bug/jour) il produise du code meilleur pour plein de raison psychologiques difficilement mesurable :
Exemple, moi :
1) quand je suis seul je code comme un porc, personne peut me relire sur le fond, dans les revues les collegues s'attaquent qu'aux erreurs esthétiques, un if mal indenté, des variables qui respectent pas la nomenclature,...) sans savoir si le code fonctionne réellement. Evidement je suis un Dieu et je fais aucun bug (en fait j'ai développer une technique secrete "masquage de potentielle probleme sous une argumentation fumeuse", et quelques points en "correction de mes bugs en revue de code des autres bugs... et parfois des miens), mais tout le monde ne l'est pas.
2) quand un gars est a coté de moi et comprend ce que je fais, à la premiere erreur il me le fait remarqué. Evidement au début ça gonfle et j'ai envie de lui faire manger mon clavier, mais quand on se rend compte des résultats (j'ai pas de bug à corriger pendant les réunions, donc je peux dormir), j'adhére totalement en tant que développeur.
Si j'étais manager je l'appliquerais immédiatement. Mais, perso, je suis pour une approche hybride:
- phase de prototyping : méthode agile 100%, release early/often, codage par pair, test driven development,...
- phase de développement industriel traditionel (si absolument nécessaire pour un grand compte par exemple, une fois l'archi trouvée et validée) : on reprend le cycle en V avec un beau cahier des charges, un plan de test bien propre, un développement... qui est déjà fait un test sur terrain bien lourd et bien complet.
[^] # Re: Rire jaune
Posté par Stibb . En réponse au journal Linuxfr en J2EE. Évalué à 5.
Savent pas qu'un bug peut être conceptuel, ie, pas de bug de codage mais que l'archi en elle meme puisse etre vereuse, et qu'il faille tout changer.
sans savoir qu'il y a une contradiction forte entre la "productivité" (bien souvent résumé au nombre de ligne de code écrite, ou, parfois, au nombre de bugs résolu ou de feature développé/semaine) et "qualité". Les deux partages la même quantité de ressource (le cerveau de l'ingé), donc on peut pas tirer sur l'un sans diminuer 'autre.
Et il savent ce que sont les maths, c'est pas dûr je te dis :
- un ingé de base corrige 1 bug/jour
- deux ingé corrigeront 2 bug/jour
...
Ca lui viendrait pas à l'esprit qu'un bug mal corrigé puisse en générer 15.
si 2 ingé sur le même poste n'écrivent qu'1 feature/jour (ou corrige qu'1 bug/jour) il produise du code meilleur pour plein de raison psychologiques difficilement mesurable :
Exemple, moi :
1) quand je suis seul je code comme un porc, personne peut me relire sur le fond, dans les revues les collegues s'attaquent qu'aux erreurs esthétiques, un if mal indenté, des variables qui respectent pas la nomenclature,...) sans savoir si le code fonctionne réellement. Evidement je suis un Dieu et je fais aucun bug (en fait j'ai développer une technique secrete "masquage de potentielle probleme sous une argumentation fumeuse", et quelques points en "correction de mes bugs en revue de code des autres bugs... et parfois des miens), mais tout le monde ne l'est pas.
2) quand un gars est a coté de moi et comprend ce que je fais, à la premiere erreur il me le fait remarqué. Evidement au début ça gonfle et j'ai envie de lui faire manger mon clavier, mais quand on se rend compte des résultats (j'ai pas de bug à corriger pendant les réunions, donc je peux dormir), j'adhére totalement en tant que développeur.
Si j'étais manager je l'appliquerais immédiatement. Mais, perso, je suis pour une approche hybride:
- phase de prototyping : méthode agile 100%, release early/often, codage par pair, test driven development,...
- phase de développement industriel traditionel (si absolument nécessaire pour un grand compte par exemple, une fois l'archi trouvée et validée) : on reprend le cycle en V avec un beau cahier des charges, un plan de test bien propre, un développement... qui est déjà fait un test sur terrain bien lourd et bien complet.