c'est ce qu'on a fait a un moment dans ma boite (technique de bâtard) Et ça a tellement bien marché que le client ne nous lachait plus. Le client est pas le problème (il paye pour un truc et si on lui montre une maquette il sera content), c'est en interne que ça coince. Il faudrait que le code soit parfait dès le début, alors que les specs ca évolue, les algos sont pas nécessairement optimaux au début (surtout quand les spec évoluent, c'est horrible d'optimiser un code et de se rendre comte que c'est pas la bonne chose qui est faite).
Les managers ont peur des erreurs. Pour eux c'est le mal absolu de faire des erreurs, ils ne comprennent pas qu'en faisant des erreurs (en prototypage) on apprend et que la prochaine fois (en développement réel) on code mieux. Alors ils changent le projet d'équipe... et ça recommence.
Perso, sur certains projet maintenant je me dis que j'ai vraiment écrit de la merde à un moment, et que si je devais refaire tel algo je le ferais différement. Mais si je prend pas le temps de me planter, évidement je n'apprend pas et je ponds un truc qui marche mais qui n'est pas parfait.
Faut leur apprendre à valoriser les erreurs au lieu de comptabilisé ça dans un tableau et tenter de le réduire au strict minimum. C'est ce que le développement agile promouvoit : releae often pour identifier immédiatement les soucis, et ne pas hésiter à réécrire le code from scratch quand on est dans l'impasse, au lieu de maintenir un code dépassé.
[^] # Re: Rire jaune
Posté par Stibb . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Les managers ont peur des erreurs. Pour eux c'est le mal absolu de faire des erreurs, ils ne comprennent pas qu'en faisant des erreurs (en prototypage) on apprend et que la prochaine fois (en développement réel) on code mieux. Alors ils changent le projet d'équipe... et ça recommence.
Perso, sur certains projet maintenant je me dis que j'ai vraiment écrit de la merde à un moment, et que si je devais refaire tel algo je le ferais différement. Mais si je prend pas le temps de me planter, évidement je n'apprend pas et je ponds un truc qui marche mais qui n'est pas parfait.
Faut leur apprendre à valoriser les erreurs au lieu de comptabilisé ça dans un tableau et tenter de le réduire au strict minimum. C'est ce que le développement agile promouvoit : releae often pour identifier immédiatement les soucis, et ne pas hésiter à réécrire le code from scratch quand on est dans l'impasse, au lieu de maintenir un code dépassé.