Il prends l'exemple de la rénovation de salle de bain comme si c'était une tâche standardisée…
Si le client a la même approche pour le logiciel et les travaux, l'échange avec un artisan ou un développeur sera tout aussi laborieux:
- Bonjour, je voudrais refaire ma salle de bain.
- Elle fait quelle taille? Vous voulez une douche? Une baignoire ? Un évier? Des toilettes ?
- Heu je ne sais pas moi, je veux une salle de bain normale quoi !
- Mmh bon quel est votre budget ?
- Mon budget ? Heu ben ça dépends combien ça coûte !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
je voudrais changer le bac de douche qui est fissuré
ok mais changer le bac c'est refaire le carrelage autour et ça fera moche d'avoir du carrelage différent, donc il faudrait refaire la salle de bain et en profiter pour la moderniser. Alors il faut choisir le carrelage mural, le carrelage de douche, le carrelage du sol, le type de robinetterie, le type de bac de douche, le type de pare-douche, l'éventuel sèche-serviette, le meuble, la vasque, etc, etc. Mais bon ça vaudrait le coup de refaire l'isolation sol et mur au passage, donc faut aussi choisir l'isolant sol et mur, et la couleur du plafond. Au fait vous voudrez quoi comme éclairage, combien de spots, quels emplacements, quelle couleur de lumière, etc. Au fait les prises électriques et l'arrivée/évacuation de la machine à laver, on laisse en place ou on déplace ?
Pas très différent (en volume) au final des multiples questions logicielles sur les exigences fonctionnelles (ça doit faire quoi, quelles sont toutes les fonctionnalités souhaitées, quelle IHM/CLI) et les non-fonctionnelles (volumétrie, performances, sécurité, etc.). Dans les deux situations, certaines questions sont tranchées par ce qu'on veut (initialement + les aller-retour avec le pro), par le prix, par l'esthétique, par les conseils du pro parce qu'on n'en sait rien, etc.
Pour donner une situation caricaturale, ça serait :
bonjour, je voudrais une voiture
ok, ça sera 50k€ voici les clés
merci, au revoir
(repart avec une R5 délabrée jaune fluo, une Ferrari flambante neuve, un SUV bleu ou une Majorette de 2 CV orange)
La baignoire n'est pas forcément le meilleur exemple, même si on est sur un cas typique où de l'anticipation (et donc de la discussion préalable avec le client) permet de drastiquement changer le devis de la modification. Lors du changement de baignoire chez ma belle-mère, qui a des soucis d'accessibilité, lorsque le plombier a chiffré la rénovation du système d'évacuation, il lui a proposé de faire (pour un léger surcoût) le nécessaire pour permettre de transformer rapidement la baignoire en douche à l'italienne sans refaire tous les travaux de plomberie ou de carrelage…
Et si vraiment tu trouves l'exemple de la baignoire pas assez exponentiel, il y a plein d'autres choses dans le BTP très compliquées ou coûteuses à modifier après coup (mais je te l'accorde, probablement pas exponentiel). Si on veut rester dans la salle de bain, les tuyaux coulés dans la dalle de béton ou la chape maigre, par exemple, ou encore un renfort à mettre dans le mur pour une porte coulissante ou un lavabo, une fois que le carrelage est posé ou la peinture terminée.
Et à l'inverse si chaque changement dans un logiciel était exponentiellement plus cher, on n'aurait pas inventé l'agilité et on serait resté sur un bon vieux cycle en V pour être sûr de n'avoir rien oublié…
Bref, je rejoins l'avis de Krunch : c'est la prose de quelqu'un qui n'a pas vu grand chose du monde en dehors de son environnement (et j'ajouterais de quelqu'un qui se pense faire partie d'une classe supérieure au reste du monde).
La première question qu'un développeur devrait se poser est de définir quelles sont les questions qu'il devrait se poser. Limite on appellerait ça des exigences ou des spécifications.
(Selon LinuxFr.org, en ce vendredi estival, il devrait commencer par un colloque international pour demander l'avis de toutes les autres personnes qui développent, établissant ainsi une liste exhaustive pour construire cet abri à vélo vert, ensuite on pourrait discuter du meilleur langage, des meilleurs outils et du code parfait, après on pourrait parler des tests)
Posté par Tit .
Évalué à 5 (+3/-0).
Dernière modification le 22 août 2025 à 11:40.
dans ce colloque, il est important de prévoir, me semble-t-il, une réforme du français pour le rendre non ambigüe, en effet dans "abri à vélo vert" on ne sait pas si c'est le vélo ou l'abri qui est vert, ce qui peut, malgré les outils et le code parfait, amener à la construction d'un abri qui ne correspond pas du tout aux souhaits du client parce qu'il pourrait par exemple abriter aussi les vélos bleus. par exemple on pourrait utiliser les tirets : abri-à-vélo vert ou abri à vélo-vert, ou bien les crochets [abri à vélo] vert ou abri à [vélo vert], ce ne sont que de simples exemples, bien évidemment.
j'ai travaillé longtemps avec des développeurs qui utilisaient le mot "infini" pour dire qu'un algo est trop lent…
Donc exponentiel, c'est presque pas beaucoup pour moi…
# Les artisans aussi
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+7/-0).
Il prends l'exemple de la rénovation de salle de bain comme si c'était une tâche standardisée…
Si le client a la même approche pour le logiciel et les travaux, l'échange avec un artisan ou un développeur sera tout aussi laborieux:
- Bonjour, je voudrais refaire ma salle de bain.
- Elle fait quelle taille? Vous voulez une douche? Une baignoire ? Un évier? Des toilettes ?
- Heu je ne sais pas moi, je veux une salle de bain normale quoi !
- Mmh bon quel est votre budget ?
- Mon budget ? Heu ben ça dépends combien ça coûte !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les artisans aussi
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-0). Dernière modification le 20 août 2025 à 10:37.
Expérience récente :
Pas très différent (en volume) au final des multiples questions logicielles sur les exigences fonctionnelles (ça doit faire quoi, quelles sont toutes les fonctionnalités souhaitées, quelle IHM/CLI) et les non-fonctionnelles (volumétrie, performances, sécurité, etc.). Dans les deux situations, certaines questions sont tranchées par ce qu'on veut (initialement + les aller-retour avec le pro), par le prix, par l'esthétique, par les conseils du pro parce qu'on n'en sait rien, etc.
Pour donner une situation caricaturale, ça serait :
# ce blog semble être écrit par un développeur
Posté par Krunch (site web personnel) . Évalué à 5 (+3/-0).
J'ai l'impression que le développeur qui a écrit ça n'a aucune idée de comment ça se passe dans les autres domaines.
Genre changer la baignoire après coup c'est trivial ?
C'est aussi vrai hors de l'informatique.
C'est aussi vrai hors de l'informatique.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ce blog semble être écrit par un développeur
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+1/-1).
Non, mais ce n'est pas forcément exponentiellement plus cher d'enlever une baignoire pour la remplacer par une autre.
Il peut probablement arriver d'autres problèmes plus compliqués à résoudre.
[^] # Re: ce blog semble être écrit par un développeur
Posté par aiolos . Évalué à 7 (+5/-0).
La baignoire n'est pas forcément le meilleur exemple, même si on est sur un cas typique où de l'anticipation (et donc de la discussion préalable avec le client) permet de drastiquement changer le devis de la modification. Lors du changement de baignoire chez ma belle-mère, qui a des soucis d'accessibilité, lorsque le plombier a chiffré la rénovation du système d'évacuation, il lui a proposé de faire (pour un léger surcoût) le nécessaire pour permettre de transformer rapidement la baignoire en douche à l'italienne sans refaire tous les travaux de plomberie ou de carrelage…
Et si vraiment tu trouves l'exemple de la baignoire pas assez exponentiel, il y a plein d'autres choses dans le BTP très compliquées ou coûteuses à modifier après coup (mais je te l'accorde, probablement pas exponentiel). Si on veut rester dans la salle de bain, les tuyaux coulés dans la dalle de béton ou la chape maigre, par exemple, ou encore un renfort à mettre dans le mur pour une porte coulissante ou un lavabo, une fois que le carrelage est posé ou la peinture terminée.
Et à l'inverse si chaque changement dans un logiciel était exponentiellement plus cher, on n'aurait pas inventé l'agilité et on serait resté sur un bon vieux cycle en V pour être sûr de n'avoir rien oublié…
Bref, je rejoins l'avis de Krunch : c'est la prose de quelqu'un qui n'a pas vu grand chose du monde en dehors de son environnement (et j'ajouterais de quelqu'un qui se pense faire partie d'une classe supérieure au reste du monde).
[^] # exponentiel ?
Posté par LaurentClaessens (site web personnel) . Évalué à 3 (+1/-0).
J'ai compris que le mot «exponentiel» est en général utilisé juste comme synonyme de «très rapidement».
Mais ici, il semble que le mot «exponentiel» ne soit même pas utilisé pour exprimer une vitesse.
Est-ce que ici je dois comprendre «exponentiel» comme simplement «beaucoup» ?
[^] # Re: exponentiel ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4 (+2/-1).
Je ne sais pas, c'est bien le genre de question qu'un développeur devrait se poser avant d'utiliser ce mot, je suppose?
[^] # Re: exponentiel ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
La première question qu'un développeur devrait se poser est de définir quelles sont les questions qu'il devrait se poser. Limite on appellerait ça des exigences ou des spécifications.
(Selon LinuxFr.org, en ce vendredi estival, il devrait commencer par un colloque international pour demander l'avis de toutes les autres personnes qui développent, établissant ainsi une liste exhaustive pour construire cet abri à vélo vert, ensuite on pourrait discuter du meilleur langage, des meilleurs outils et du code parfait, après on pourrait parler des tests)
[^] # Re: exponentiel ?
Posté par Tit . Évalué à 5 (+3/-0). Dernière modification le 22 août 2025 à 11:40.
dans ce colloque, il est important de prévoir, me semble-t-il, une réforme du français pour le rendre non ambigüe, en effet dans "abri à vélo vert" on ne sait pas si c'est le vélo ou l'abri qui est vert, ce qui peut, malgré les outils et le code parfait, amener à la construction d'un abri qui ne correspond pas du tout aux souhaits du client parce qu'il pourrait par exemple abriter aussi les vélos bleus. par exemple on pourrait utiliser les tirets : abri-à-vélo vert ou abri à vélo-vert, ou bien les crochets [abri à vélo] vert ou abri à [vélo vert], ce ne sont que de simples exemples, bien évidemment.
[^] # Re: exponentiel ?
Posté par moi1392 . Évalué à 4 (+2/-0).
j'ai travaillé longtemps avec des développeurs qui utilisaient le mot "infini" pour dire qu'un algo est trop lent…
Donc exponentiel, c'est presque pas beaucoup pour moi…
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.