Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

Qu'est-ce qui vous fascine automatiquement ?

  • 51 308 réponses
  • 526 participants
  • 2 021 862 vues
  • 396 followers
Sujet de la discussion Qu'est-ce qui vous fascine automatiquement ?
Et hop encore un autre sujet inutile !
Ce coup ci parlez nous des petits trucs devant lesquels vous scotchez.
Moi c'est :
-Les aiguillages de trains (surtout quand y'en a plein)
-Les usines d'embouteillage à la chaine
-Un DJ qui scratche (pas comme moi au couteau !)
-Un beau circuit de train électrique bien décorré
Afficher le sujet de la discussion
46351
Citation :
Question ouverte: est-ce que seule la SSII est à blâmer (je ne prends pas leur défense il n'y pas que du bon chez eux) ?

Pour avoir travaillé pas mal en SSII (Dataid) je peux dire que la réponse est clairement non (pour mon cas personnel.
Les prestataires sont baladés de droite à gauche, les cahiers des charges changent toutes les 5mn, il règne à tous les niveaux un parfum d'amateurisme et de gabegie. La SSII se contente de s'enrichir sans se poser de questions.
46352
ESN :oops2:

.:MonSoundCloud:.

 

Le Seigneur des Marteaux
"Un marteau pour les aplatir tous."

46353
Citation :
Je me demande s'il y a un seul projet public confié à une SSII qui a été réussi dans les temps.
Voir même juste fini, même avec du retard.
Sans être un carnage inutilisable.

Fini avec du retard, et largement utilisé : oui, dans le contrôle aérien on en a plein.

Après attention, c’est facile de jeter la pierre, mais dès qu’un projet est très gros, sa complexité explose. Quand c’est très « métier » et très vaste, bon nombre de questions et de solution apparaîssent « en faisant le truc ». D’où une grosse partie des dérives.

C’est vrai en informatique, mais en dehors aussi : les premiers Airbus par exemple... Pourtant on a bien fait de persévérer. Et c’est une initiative étatique.

Mais c’est encore plus vrai en informatique. En effet, le code source représente en fin de compte une spécification détaillée. Si dès l’appel d’offre on donnait une spécification très détaillée... bien il n’y aurait plus grand chose à faire derrière ; mais on reporte le gros du travail dans l’appel d’offre.

Quand on fait du BTP, c’est différent : les plans constituent une spécification assez détaillée, et il reste énormément de boulot après.

Évidemment quand le boulot qu’on fait est un boulot qu’on peut faire tout seul, on peut avoir du mal à imaginer la difficulté qu’il y a derrière tout ça. Ce « ça » est en fait de l’ingéniérie des systèmes (« système » non pas au sens de « système informatique », mais au sens « d’ensemble complexe de trucs liés entre eux, éventuellement de nature hétérogène »).

Ce n’est pas lié à l’informatique et aux SSII. Auguste Detœuf en parle déjà largement en 1926 dans son fameux livre.
https://fr.wikipedia.org/wiki/Auguste_Detœuf

D’ailleurs c’est très drôle ce bouquin. Il y a plein de trucs qui semblent avoir été écrits cette année, et après ça parle de voitures à cheval !

[ Dernière édition du message le 23/07/2018 à 15:00:56 ]

46354
Mais si la difficulté de la tâche comme je la décris est bien réelle et à ne pas sous-estimer, s’y ajoutent aussi les problèmes évoqués par Djardin, Picto et Migo.

Mais à partir du moment où on fait un truc gros (donc avec beaucoup de gens) et différent de ce qu’on a fait avant, on est obligé de se coltiner ces difficultés.

Autre célèbre bouquin :
The Mythical Man-Month.

Rien que le titre... C’est aussi un gros retour d’expérience sur un projet de 1000 hommes x an.

[ Dernière édition du message le 23/07/2018 à 15:06:53 ]

46355
Quant au dérapage des coûts, et autre "On a dépensé X millions pour cette bouse, alors on va s'en servir quand même", voici une petite vidéo explicative :

46356
Citation :
On a dépensé X millions pour cette bouse, alors on va s'en servir quand même

Je n’ai pas encore vu la vidéo. Donc je réponds juste là-dessus.

Néanmoins la solution « on va tout refaire », sous-entendu « cette fois on va tout réussir parfaitement », n’est pas aussi bonne qu’on pourrait croire. On peut évidemment refaire des erreurs, différentes, et pas forcément moindre. Ça peut être un miroir aux alouettes.
46357
Citation :
Néanmoins la solution « on va tout refaire », sous-entendu « cette fois on va tout réussir parfaitement », n’est pas aussi bonne qu’on pourrait croire.


c'est pas les contrôleurs aériens qui tournent encore sur W95 ou W2000 ? :-D

Quand je conduis pas j'ai peur.

46358
Vouloir refaire un logiciel bugué, sans vouloir refaire d'abord l'équipe et l'environnement qui l'ont conçu, c'est refaire le même logiciel bugué.

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

46359
Citation de Alx33 :
Citation :
Néanmoins la solution « on va tout refaire », sous-entendu « cette fois on va tout réussir parfaitement », n’est pas aussi bonne qu’on pourrait croire.


c'est pas les contrôleurs aériens qui tournent encore sur W95 ou W2000 ? :-D


En France il y a au moins deux systèmes pour l’image radar (il y a plein d’autres trucs), un en centre en route, et l’autre dans les tours.

Le premier était sur Digital Unix Tru64, et est sur Linux depuis une dizaine d’années.

Le second est sur Windows, je crois que c’est 2000 effectivement. Il a été porté sur Linux, et cette version est déjà en service sur quelques sites, et en cours de déploiement sur les autres.

L’achat de nouveaux systèmes a été lancé il y a quelques années, et ils devraient entrer en service à partir de 2022.

Classiquement il faut environ 10 ans pour faire un système, et on s’en sert ensuite pendant 20 ans. Évidemment chaque année il y a des petites évolutions, pas mal de bugs à corriger, et des évolutions assez importantes tous les 5 ans.

Tout tourne évidemment à H24 7j/7. Il y a des interconnexions qui relient à peu près tout. Donc les changements, qui ne peuvent se faire que par morceaux, sont assez compliqués.

C’est à peu près similaire dans tous les pays. D’ailleurs les pays où on trouve les trucs les plus vieux sont les pays les plus gros, et dont le développement de l’aérien s’est produit le plus tôt. C’est logique.
Par exemple, en 2000, à JFK (New York) il y avait encore des ordinateurs à composants discrets (= sans microprocesseurs) !

[ Dernière édition du message le 23/07/2018 à 18:03:06 ]

46360
Citation de Djardin :
Vouloir refaire un logiciel bugué, sans vouloir refaire d'abord l'équipe et l'environnement qui l'ont conçu, c'est refaire le même logiciel bugué.

Oui mais changer d’équipe est aussi une autre page blanche, qui ne garantit rien.

Bref, c’est pas si facile.
46361
Citation de Dr :
Néanmoins la solution « on va tout refaire », sous-entendu « cette fois on va tout réussir parfaitement », n’est pas aussi bonne qu’on pourrait croire. On peut évidemment refaire des erreurs, différentes, et pas forcément moindre. Ça peut être un miroir aux alouettes.


Certes, mais ce n'est pas le propos. Le biais cognitif évoqué est de prendre en compte les sommes déjà perdues.
Il ne faut prendre en compte que ce qui reste à dépenser (en argent, en efforts, en risques, etc.) pour atteindre l'objectif fixé. Même quand c'est objectivement plus intéressant, il est très difficile de faire table rase, surtout si ca implique d'admettre qu'on s'est trompé.
46362
Citation :
Il ne faut prendre en compte que ce qui reste à dépenser (en argent, en efforts, en risques, etc.) pour atteindre l'objectif fixé.

C’est sûr. Mais la table rase, souvent c’est pas simple, et on ne sait pas non plus combien ça va recoûter. Ça peut aussi être un bon moyen de se planter encore plus !
46363
Oui, mais ni plus ni moins que d'estimer le reste-à-faire d'un développement qui a été laborieux.
46364
Justement si. Dans beaucoup de cas on compare d’un côté un truc fait à 75%, et dont une bonne partie a été identifiée en faisant, et d’un autre côté un truc pas commencé, dont la proportion sous-estimée risque d’être plus élevée (car plus c’est gros, plus on se gourre).

La question est surtout : est-ce que le truc bien avancé fait pas mal de choses correctement, et dans quelle mesure on peut corriger ses tares ?

Par exemple pour Hubble, plutôt que d’en lancer un nouveau, on corrige numériquement au sol les erreurs de calcul de son miroir.
46365
Ce que je veux dire, c'est que si en faisant un truc ça a foiré et qu'on refait exactement le même truc, ça devrait re foirer exactement pareil.

Sauf s'il y a principalement de l'aléatoire et de la chance.

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

46366
Je pars du principe que l'expérience gagnée dans le foirage est utilisée de manière équivalente dans le retapage du projet foiré, et dans un nouveau projet from scratch.
46367
Oui et non.

L'expérience est utile si on s'en sert.

Si tu foires ton premier concert parce-que tu n'es pas accordé, mais que tu décide quand même de ne pas t'accorder au deuxième, l'expérience n'aura servi à rien à ça sera toujours de la merde.

Quand je dis "changer d'équipe", c'est pas repartir à 0, c'est virer certains éléments toxiques, donner plus d'autonomie à certains, ou encadrer mieux d'autres, etc.

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

46368
Faut pas oublier qu'il y a 20 ou 30 ans on programmait en linéaire, et la maintenance du code demandait beaucoup de rigueur et de boulot.
Avec la programmation modulaire (et par objet, qui j'imagine est utilisée pour les projets modernes) on gagne beaucoup de temps et de souplesse (si le boulot est bien fait bien sûr).
Bon mes infos sont sans doute pas à jour, vu que mon passé d'informaticien c'était y a, ouuhhhh.... longtemps
46369
Le soucis c'est rarement le code, le langage, la techno.

Par contre, le turnover, le fait de n'avoir quasiment que des débutants démotivés, le management d'armée mexicaine et les embrouilles politiques, l'interdiction de communiquer, le fait d'être toujours sous pression avec des deadlines décidées par on ne sait pas qui ... Ça joue un peu plus.

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

46370
Je voulais juste dire que dans ces conditions, refaire à partir de zéro risque d'être moins coûteux que de poser des rustines
46371
Citation de Jimbass :
Oui, mais ni plus ni moins que d'estimer le reste-à-faire d'un développement qui a été laborieux.

Citation de Dr :
Ben si. Dans beaucoup de cas on compare d’un côté un truc fait à 75%, et dont une bonne partie a été identifiée en faisant, et d’un autre côté un truc pas commencé, dont la proportion sous-estimée risque d’être plus élevée (car plus c’est gros, plus on se gourre).


D’ailleurs depuis quelques années je bosse sur un exemple encore plus radical. D’un côté on a lancé le projet d’acheter un truc tout neuf, sur étagère. De l’autre, je m’occupe du portage sur Linux d’un logiciel qui tourne sur des machines de 1996 (Bull / IBM AIX 4.2). Côté équipe portage, on s’est un peu forcé à mentir pour faire un planning délibérément court. On a fait ça parce-que le planning du projet d’achat nous semblait très fortement sous-estimé, et du coup, si l’écart était faible, le portage ne serait pas lancé, ce qui présentait le risque de continuer encore pas mal (trop) d’années avec des matériels et logiciels désormais très difficiles à maintenir.

On pourrait donc dire : achat = départ d’une feuille blanche, portage = évolution moyenne d’un truc bien avancé.

Grand bien nous a pris de mentir un peu ! Évidemment notre planning a dérivé, et plus que ce qu’on pensait. Mais l’autre a dérivé infiniment plus. Et au final on voit bien que les temporalités ne sont absolument pas les mêmes. De fait, ce portage va nous permettre de tenir sereinement encore un bon moment (sûrement 10 ans avant qu’on arrête ce système sur le dernier des 40 sites où il est déployé), en attendant qu’il soit remplacé par le nouveau.

Et le nouveau projet s’est heurté à des difficultés auxquelles on ne s’attendait vraiment pas (même si justement on sait que ça ne se passe jamais comme prévu). Pour une fois l’appel d’offre (international) et le contexte étaient très bien engagés. On a eu pas mal de réponses d’industriels, mais ils se sont petit-suicidés avec un effet de série assez incroyable.

Un qui était bien pressenti avait tout bon, sauf qu’il a obstinément refusé de chiffrer (et aussi de réaliser) de quoi se mettre en conformité avec les règlements européens (essentiellement de la documentation).

Un deuxième, certainement le leader pour les grands pays, avait un produit encore mieux, mais a non seulement refusé de franciser une partie de sa doc (alors qu’on a vu pendant les démos qu’il a plein d’employés parlant très bien français), mais a surtout complètement salopé la deuxième série de démonstrations, celle avec les contrôleurs, qui du coup ne croyaient plus du tout à cette solution.

Le troisième, très connu, pouvait nous proposer soit un très gros truc dans lequel on est déjà impliqué, soit un truc de taille moyenne, bien a eux, éprouvé, qui aurait bien convenu. Mais non, il a répondu avec des produits de seconde zone, même pas prévus pour fonctionner ensemble.

Un quatrième, d’un grand pays voisin, a répondu avec un produit sympa, mais clairement destiné à des petits terrains et non les plus gros. Ce qui était pourtant le cœur de l’appel d’offre (Orly et Roissy...).

Un cinquième a répondu avec un truc constitué d’un constituant bien éprouvé et représentant environ 30% des fonctions, et la promesse d’un développement merveilleux pour le reste, alors que dans notre appel d’offre on a bien dit qu’on voulait un système complet, déjà utilisé depuis plusieurs années sur au moins un gros aéroport.

Bref, c’est rarement simple ces histoires...
46372
Citation de Jimbass :
Quant au dérapage des coûts, et autre "On a dépensé X millions pour cette bouse, alors on va s'en servir quand même", voici une petite vidéo explicative :



Je trouve qu’il y a beaucoup de biais de simplification dans sa vidéo !

Voire carrément des erreurs. Pour le Concorde, on savait dès le début que ce ne serait pas rentable. Mais son but premier était de reprendre confiance, dans une certaine fierté nationale, et dans une audace technologique et industrielle. Ça a certainement facilité la voie à Airbus, même si, pour Airbus aussi, il y a eu 36 fois l’occasion de jeter l’éponge et abandonner.

Je crois que c’était Ziegler (l’un des créateurs d’Airbus) qui racontait ça dans une conférence : Giscard l’avait convoqué pour savoir où en était ce projet ; et Ziegler devait lui annoncer que ça démarrait, certes mollement, mais ça démarrait. Un appareil avait été vendu... :bave: (un A300)


Pour résumer, je dirais que le piège de ce genre de simplification est similaire à la différence entre un énoncé de mathématiques (voire un énoncé scolaire), et un problème plus bassement concret et matériel :
- dans un problème mathématique, l’énoncé est souvent court, toujours clair et complet ; par contre la résolution peut faire appel à des trucs compliqués
- dans un problème industriel, généralement l’énoncé est très vaste (en volume d’infos mais aussi dans leur nature variée), assez incomplet ; mais la résolution repose sur des actions plus simples, avec des compromis pifométriques.


Alors oui, bien sûr qu’il y a un biais humain absurde à vouloir rentabiliser des coûts irrécupérables. Mais ce serait une grosse erreur, très simplificatrice, de mettre ça un peu partout. Rien que sur son exemple de départ, il compare des carottes et des langages objet. Donc bof.
46373
Citation :
- dans un problème mathématique, l’énoncé est souvent court, toujours clair et complet ; par contre la résolution peut faire appel à des trucs compliqués
- dans un problème industriel, généralement l’énoncé est très vaste (en volume d’infos mais aussi dans leur nature variée), assez incomplet ; mais la résolution repose sur des actions plus simples, avec des compromis pifométriques.


ça me fait penser à mes profs d'automatiques en école d'ingés : on avait toujours dans les exos des système avec un ou deux paramètres à asservir maximum, et plein de calculs théoriques.
Puis les profs de l'école ont monté un drone, avec donc énormément plus de paramètres à prendre en compte puisque dans le monde réel. Donc des calculs de malade. Et on leur demande quelle formule ils utilisent pour les calculs :
"on essaie avec des valeurs qui paraissent logique, puis on adapte en testant en condition réelle".

:-D

aucun calcul, juste de l'itération et des essais empirique !

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

46374
Un français qui part à Los Angeles et qui lance le mouvement "Moped" sur la West Coast, tu le crois ça ?

Fan de 103 SP et autre 51 black, tu vas kiffir



Y'a des mecs y sont bons quand même. :8)

[ Dernière édition du message le 23/07/2018 à 22:53:11 ]

46375
Djardin :bravo:

Je ne vais pas dire que c’est une règle, au contraire, mieux vaut essayer de s’appuyer sur les bases les plus solides possibles. Mais il faut aussi faire gaffe à vouloir trop simplifier les choses. D’ailleurs en économie, ils ont tellement voulu avoir des équations mathématiques (voire des équations qu’on sache résoudre symboliquement), que ça a fini par partir largement dans le n’importe quoi.

Dans The Limits to growth, non seulement Donella et Dennis Meadows n’ont pas simplifié leurs équations (qui sont plutôt nombreuses que compliquées), mais ils ont souligné que leurs résultats numériques ne valent pas trop pour déterminer les années auxquelles les problèmes se poseront, mais plutôt pour l’évolution générale du système, autrement dit, la forme des courbes.

[ Dernière édition du message le 23/07/2018 à 22:58:41 ]