Excellent article malgré une vulgarité gratuite. Il manque quand même une raison : parfois, on fait des erreurs, tout simplement. Et plus qu'on ne l'imagine. Un matin difficile, un peu de paresse ou une distraction et on glisse des erreurs, même dans la conception.
Autre point, l'informatique n'est pas le bâtiment : on peut remanier beaucoup plus facilement. Donc critiquer « on aurait dû faire comme ça » ne sert à rien. Il faut faire passer l'idée qu'en logiciel évolue toujours, non seulement en terme de fonctionnalité mais dans sa structure même, dans ses technologies.
La vulgarité est pour moi l'humanisation d'un article, l'humain est vulgaire de base. Enfin les gouts et les couleurs.
Par contre oui l'erreur est humaine, et il n'y a que ceux qui ne font rien qui n'en font jamais, par contre faut savoir les reconnaitre, ce que dans ma boite, la majorité des devs ne font pas.
L'informatique est plus proche du bâtiment que l'on crois, il y a aussi des fondations, qui sont très complexe à toucher, car la moindre modification, et tout s'écroule, et faire des tests n'est toujours pas faisable. Je l'ai vu très souvent ou tout un SI est dépendant d'un vieux système qui d'un coup n'est plus maintenu, mais qui est le coeur de se SI.
C'est vrai, moi le premier. Dans l'agilité, il y a une réflexion sur « assumer ses erreurs » à la fois pour les reconnaître mais aussi les dédramatiser, leur accorder du temps et passer à autre chose. On ne fait pas de v1.0 parfaite du premier coup. On est d'accord.
On flatte énormément l'orgueil des développeurs. L'exemple des rockstar cité dans l'article est révélateur. Ça n'aide pas à accepter que « je vais faire des erreurs, j'en ferai plus sous la pression, cela doit être pris en compte dans mon travail de dév ».
L'informatique est plus proche du bâtiment que l'on crois, il y a aussi des fondations, qui sont très complexe à toucher, car la moindre modification, et tout s'écroule
Je suis tout à fait d'accord avec toi. J'utilise souvent le secteur du bâtiment comme analogie pour expliquer l'informatique : on retrouve les fondations, la distinction interface/arrière-boutique, l'architecture, et plein d'autres points communs.
Je voulais compléter en disant que le dév a une qualité qui permet de dépasser certaines limite du bâtiment : tout est virtuel. C'est juste une question de moyen et de volonté. Avec l'analogie du bâtiment, on est tenté de négliger ce point.
Si on touche un brique essentielle, on peut toujours remanier sans repartir d'une feuille blanche (et subir l'effet tunnel).
Pour éviter les régressions et attaquer vaillamment le remaniement, le pire scénario que je vois est d'avoir une batterie de test selenium sur la prod, de sorte qu'on puisse valider la prod à chaque déploiement. Quand t'es dans la mouise à ce point, faut assumer :-D heureusement, pas mal de projets peuvent avoir une préprod.
C'est ça qu'on a pas dans le bâtiment : cloner une maison pourrite, améliorer le clone, y habiter une journée et une nuit pour s'assurer que tout va bien et remplacer l'originale. Bien des architectes rêveraient de pouvoir faire ça !
Une approche comme ça est plus coûteuse qu'une réécriture complète, mais le retour est immédiat et plus certains. Ça reste coûteux comme toute dette impayées depuis des générations ^^
Après on n'aide pas les gens à assumer leurs erreurs, il suffit de voir les “réunion de crise”, la première question que les responsables posent, c'est “qui a fait une erreur ?”. La dernière réunion du type que j'ai faite, je suis partie au bout de 30 secondes, en disant “Je pensais être là pour trouver une solution, pas un coupable”.
Mais on travail dans un mauvais sens, dernière grosse erreur sur le SI, j'ai d'abord pensé à une erreur de conf de mon cotés, puis j'ai contacté les devs, qui m'ont envoyés chier. Pour finir j'ai regarder le code sur le SVN, et j'ai vu que y'avait une base de données de recette en dur. J'ai remonté ça, et chercher un plan d'amélioration. Seul amélioration, j'ai perdu les droits SVN.
Excellent article malgré une vulgarité gratuite. Il manque quand même une raison : parfois, on fait des erreurs, tout simplement. Et plus qu'on ne l'imagine. Un matin difficile, un peu de paresse ou une distraction et on glisse des erreurs, même dans la conception.
Autre point, l'informatique n'est pas le bâtiment : on peut remanier beaucoup plus facilement. Donc critiquer « on aurait dû faire comme ça » ne sert à rien. Il faut faire passer l'idée qu'en logiciel évolue toujours, non seulement en terme de fonctionnalité mais dans sa structure même, dans ses technologies.
La vulgarité est pour moi l'humanisation d'un article, l'humain est vulgaire de base. Enfin les gouts et les couleurs. Par contre oui l'erreur est humaine, et il n'y a que ceux qui ne font rien qui n'en font jamais, par contre faut savoir les reconnaitre, ce que dans ma boite, la majorité des devs ne font pas.
L'informatique est plus proche du bâtiment que l'on crois, il y a aussi des fondations, qui sont très complexe à toucher, car la moindre modification, et tout s'écroule, et faire des tests n'est toujours pas faisable. Je l'ai vu très souvent ou tout un SI est dépendant d'un vieux système qui d'un coup n'est plus maintenu, mais qui est le coeur de se SI.
C'est vrai, moi le premier. Dans l'agilité, il y a une réflexion sur « assumer ses erreurs » à la fois pour les reconnaître mais aussi les dédramatiser, leur accorder du temps et passer à autre chose. On ne fait pas de v1.0 parfaite du premier coup. On est d'accord.
On flatte énormément l'orgueil des développeurs. L'exemple des rockstar cité dans l'article est révélateur. Ça n'aide pas à accepter que « je vais faire des erreurs, j'en ferai plus sous la pression, cela doit être pris en compte dans mon travail de dév ».
Je suis tout à fait d'accord avec toi. J'utilise souvent le secteur du bâtiment comme analogie pour expliquer l'informatique : on retrouve les fondations, la distinction interface/arrière-boutique, l'architecture, et plein d'autres points communs.
Je voulais compléter en disant que le dév a une qualité qui permet de dépasser certaines limite du bâtiment : tout est virtuel. C'est juste une question de moyen et de volonté. Avec l'analogie du bâtiment, on est tenté de négliger ce point.
Si on touche un brique essentielle, on peut toujours remanier sans repartir d'une feuille blanche (et subir l'effet tunnel).
Pour éviter les régressions et attaquer vaillamment le remaniement, le pire scénario que je vois est d'avoir une batterie de test selenium sur la prod, de sorte qu'on puisse valider la prod à chaque déploiement. Quand t'es dans la mouise à ce point, faut assumer :-D heureusement, pas mal de projets peuvent avoir une préprod.
C'est ça qu'on a pas dans le bâtiment : cloner une maison pourrite, améliorer le clone, y habiter une journée et une nuit pour s'assurer que tout va bien et remplacer l'originale. Bien des architectes rêveraient de pouvoir faire ça !
Une approche comme ça est plus coûteuse qu'une réécriture complète, mais le retour est immédiat et plus certains. Ça reste coûteux comme toute dette impayées depuis des générations ^^
Après on n'aide pas les gens à assumer leurs erreurs, il suffit de voir les “réunion de crise”, la première question que les responsables posent, c'est “qui a fait une erreur ?”. La dernière réunion du type que j'ai faite, je suis partie au bout de 30 secondes, en disant “Je pensais être là pour trouver une solution, pas un coupable”. Mais on travail dans un mauvais sens, dernière grosse erreur sur le SI, j'ai d'abord pensé à une erreur de conf de mon cotés, puis j'ai contacté les devs, qui m'ont envoyés chier. Pour finir j'ai regarder le code sur le SVN, et j'ai vu que y'avait une base de données de recette en dur. J'ai remonté ça, et chercher un plan d'amélioration. Seul amélioration, j'ai perdu les droits SVN.
Ah ouai… O_O Bah démissionne ! Tu peux ?