Discussion :

[MichaelREMY]

En lisant cela, je me doutais bien que peu de gens seraient d'accord avec lui.
Moi je le suis car j’ai vu le monde changeait en 30ans de code…
il y a une double lecture à sa vision qu’il pronne et valorise dans le fait d’avoir un code (accomplir un projet) fait par une seul personne qui suit un plan et une ligne droite documentée plutôt qu'un code écrit par 1000 personnes avec des techniques et nomenclatures différentes et pas commentés ou hasardeusement.

Une personne l'a dit plus haut, c'est la "faute du manager" car un manager des années 2010 préfère présenter un projet qui marche fait par 1000 personnes plutôt que le même projet qui marche fait par 1 seule personne; c'est une façon de s'auto-congratuler du management (et aussi d'augmenter les ressources et la valeur de son poste).
C'est comme quand un PDG est fier de son entreprise, il préfère dire qu'il a atteint ce sommet avec 1000 salariés plutôt qu'avec peu, ça le valorise...

C'est le monde et ses valeurs qui changent, il faut s'y faire. On est passé de l'aire du Héros (accomplissement seul très bien considéré) à l'air du partage (accomplissement collectif mieux valorisé que l'accomplissement individuel qui est dévalorisé voire critiqué négativement).
Le fait-tout-seul n’a plus sa place maintenant dans un pays « pauvre » qui essaie de s’en sortir avec des solutions de groupe.

En une phrase : « faire seul est mal alors que faire à plusieurs est forcément mieux".
Le monde a changé et certains talents individuels n'ont plus leur place dans ce nouveau monde du tout-partagé.

[Matthieu Vergne]

Une conséquence logique est que le développeur estime que les méthodologies à l’instar de l’Agile sont plutôt des outils de management. Elles ne viennent pas pour aider à créer de meilleurs logiciels, dans la mesure où elles sont facilement détournées par le management.

On revient à une discussion d'il y a quelque semaines je crois, sur le fait que l'agile ne permet pas de faire du meilleure code. Je ne peux donc qu'être d'accord sur ce point.

C'est malheureusement vrai dans beaucoup d'autres domaines.

La recherche par exemple : vive les publications ! Les prises de conscience ? La révision des paradigmes ? Monte d'abord ton index H et après on en parlera.

Je trolle sûrement un peu, mais bon, faut que ça sorte. {^_^}

[DonQuiche]

Heureusement que nous avons des managers et des commerciaux pour leur mettre tous nos échecs sur le dos !






Cette réaction se réfère pas à un commentaire en particulier. Voyez-y plutôt un ressenti général.

[Haseo86]

Ça ressemble pas mal à mon quotidien sur la plupart des points, mais je ne suis pas totalement d'accord avec l'analyse de la cause. En tout cas pour ce qui me concerne, la direction de l'entreprise n'est que moyennement responsable, c'est vraiment au niveau de l'encadrement du projet que ça coince, avec en prime une bonne couche d'incompétence technique

[Uranne-jimmy]

Le coup de gueuler sur l'ingénieur parce qu'il ne connait rien aux problèmes de la discipline, qu'il ne fait que gérer des timings et des gens, je connais ça dans beaucoup de métier. Moi même en temps que technicien de recherche en biologie et informaticien en même temps, ces deux disciplines sont touché par ce problème courant. Chez nous on a décidé de dire que ça provenait de la façon dont les ingénieurs sont formés : dans les écoles d'ingé, on leur apprend la théorie, le managment mais pas la pratique et surtout l'expérience. Pour moi un bon ingé est surtout un ancien technicien qui a un aperçu réel de comment on se bat au niveau en dessous.

[NSKis]

Un logiciel est l'oeuvre d'un être humain... Et comme le dit le proverbe: "L'erreur est humaine"!!!

Alors parler de "l'âge des logiciels ratés"...

[cervo]

Je dirai qu'il y a une réelle contrainte liee au temps de Dev, les entreprises veulent le top du top en un rien de temps pour montrer leur expertise oubliant que produit robuste == temsp , c'est clair que le management pousse le dev à ne même pas se surpasser pour sortir un travail robuste !

[Luckyluke34]

il y a une double lecture à sa vision qu’il pronne et valorise dans le fait d’avoir un code (accomplir un projet) fait par une seul personne qui suit un plan et une ligne droite documentée plutôt qu'un code écrit par 1000 personnes avec des techniques et nomenclatures différentes et pas commentés ou hasardeusement.

Entre les deux, il y a peut-être un juste milieu ? Du code écrit par non pas 1000 mais 10 personnes ayant des standard de qualité fixés collaborativement par exemple.

En une phrase : « faire seul est mal alors que faire à plusieurs est forcément mieux".

Forcément non, mais dans une industrie où beaucoup d'acteurs ont un turnover de 15, 20 voire 30% dans certaines SSII, faire seul est souvent un suicide à moins de prévoir de grosses et fréquentes périodes de passage de relais où à chaque fois le nouvel arrivant récupère tout ce qu'a fait son prédécesseur. Je ne dis pas sur des projets one-shot très courts du style petit site web "jetable" pour un événement particulier, ou pour de la R&D sur un sujet très pointu où les compétences sont rares. Mais sur des projets business destinés à vivre une dizaine d'années avec de la maintenance, faire seul est très risqué (quid si le développeur quitte la boîte précipitemment ? décède ? ...)

[Tryph]

[...]
Prenons le PHP par exemple.
Quel code pourra tenir proprement et solidement plusieurs versions d'affilée.
[...]

les entreprises ne se posent que rarement ce genre de question puisque là réponse est on ne peut plus simpliste: "on fait le code pour une version de techno, et on gardera cette version de techno tant qu'on pourra, même quand elle sera obsolète. et quand on pourra plus garder cette techno dans cette version on avisera."
c'est pas toujours comme ça, mais très souvent quand même.

---

après vouloir lister les problèmes qui aboutissent à des soft moisis, c'est peine perdue. même si certaines raisons évoquées dans l'article sont monnaie courante, il peut en exister beaucoup d'autre comme, pour prendre le premier exemple qui me vient en tête, le fait de mettre n'importe qui n'importe ou parce qu'après tout un "informaticien" est un informaticien et qu'il est capable de faire tout ce qui touche à l'informatique.
combien de décideurs font la différence entre un admin système, un DBA, un développeur, un ingénieur réseau, un spécialiste de l'ergonomie, un architecte, un chef de projet, un valideur, etc... pour beaucoup, ce sont tous des informaticiens et ils sont interchangeables à volonté et les titre qu'ils portent ne sont que des indications sur le salaire et les responsabilités qu'il faut leur donner.
et là je parle uniquement de la diversité des métiers/compétences et pas des envies de chacun genre préférence pour une techno ou aversion pour une autre. bien souvent on doit bosser avec des techno et/ou des outils qu'on a pas choisi.

alors on peut parfois se retrouver (là c'est du vécu) avec un admin réseau qui fait équipe avec un "concepteur-développeur" pour développer un soft avec une interface graphique. l'admin réseau n'a jamais rien fait d'autre que des script pour automatiser ses taches et le concepteur-développeur se retrouve à faire 95% du taf en devant corriger/refaire les 5% restant.

on peut aussi se retrouver avec un gars fan de C qui fait du Java et un fan de Java qui fait C, les 2 se démotivant et faisant le minimum car bossant chacun sur une techno qu'ils n'affectionnent pas forcément pour cause de disponibilité au moment de l'apparition du besoin.

alors je veux bien qu'il existe des contraintes qui font qu'on ne peut pas toujours placer tout de suite chaque personne à l'endroit ou elle serait le plus adaptée/à l'aise, mais ce que je constate c'est qu'une fois qu'on est sur un projet, on n'en sort bien souvent pas avant que le projet en question souffre de restrictions budgétaire, ou en démissionnant...

bref je pense que tout ça ne facilite par la qualité, mais comme je l'ai dit plus haut, ça n'est que la première autre raison à la quelle j'ai pensé et je suis à peu près certain de pouvoir en trouver d'autres en y réfléchissant un peu.

[landry161]

[truestory]
- Bonjour, je voudrais un logiciel pour ma société
- Ok, parlons-en, quels sont vos problèmes et vos besoins?
- Non, mais je veux un devis et des délais avant toute choses, afin de savoir combien ça va me coûter
- Euh...

ou encore

- Faites un effort! excel ne coûte que 50 euros par poste et vous me demandez [X dizaine de milliers d'euros] pour un ERP-QUIFAITOUT!

[/truestory]

Là je suis mort de rire

[landry161]

Aujourd'hui le développement est pour certains en tout cas ceux qui n'y connaissent rien, absolument rien un travail à la chaîne.
Donc il y a vraiment rien d'étonnant.

[gabriel.klein]

Tiens je ne suis pas d'accord avec lui

* Si on a trop de temps on overengineer...
Interfaces à tous les coins, tests sur tout.
Mais cela a un cout sur le logiciel, car il ensuite très dur de l'adapter à de nouvelles tâches. Au lieu de changer 1 truc, je dois en changer 4-5.

* On a tous une vision différente du "bien fait".

J'ai été surpris parfois de me trouver devant un logiciel qui a été sur-complexifié, dont l'architecture est complexe (car "bien faite"...).
Après un autre développeur vient dans le code car le premier est en vacance, fait aussi son architecture "parfaite" - et on finir avec un sac de noeuds

* Un "mauvais" logiciel peut être suffisant!
Je suis dans des startups, et il faut souvent montrer rapidement quelque chose.
Cela permet aux clients, aux membres de comprendre ce qu'on fait, et de développer aussi le concept.

Et parfois un truc "buggé" est suffisant.

* Avoir un "mauvais logiciel" rapidement est parfois mieux que de ne jamais avoir de logiciel.
Dans les startups, on a pas le temps ni l'argent pour avoir un logiciel parfait.
Si on peut le montrer, on peut avoir les financements pour en faire un truc parfait. Si on ne peut pas le montrer, on ne pourra jamais le montrer.

* Ne pas changer ce qui marche...
Trop souvent on veut changer des "boîtes" qui marchent tiptop (et on rajoute un bug).
Car le code n'est pas écrit parfaitement.

* On est pas des artistes...
On a tendance à se prendre pour des artistes, mais notre but n'est pas de faire des œuvres d'art (en plus sous-estimées... ).

On doit faire un outil ou un jeu, non une oeuvre d'art!

[B413-151015]

Très bonne analogie DarkHylian. Je fait le même constat. J'adore mon métier et j'ai de plus en plus de peine à le faire en entreprise. J'ai d'autant plus dur que j'ai débuté ma carrière dans une société ou l'IT était considérée et formait le cœur du business. Dans cette compagnie on prenait le temps de développer, on avait les budgets, nos demandes de réunions avec les autres département étaient prioritaires, nous étions les premiers au courant des changement à venir et inclus a toutes les discutions importantes.

Je n'ai plus jamais vu ça depuis... Et je peux dire que quand je travaillait dans cette compagnie nous finissions nos projets avant nos concurrents. Souvent tout simplement parce qu'on les démarrait a temps. On attendait pas les derniers 6 mois avant avant les délais imposés pour opérer nos changement. Nous n'étions pas Agile, toutes nos analyses devaient être complètes et signées avant développement, les cycles de production étaient long et lourd mais notre hiérarchie nous considérait et nous donnaient les outils et le temps pour faire notre travail.

Maintenant je fait de l'agilité qui se confond avec la méthode a l’arrache. Je ne programme plus, je combine des librairies entre elles. Je ne parle même plus de l'analyse qui est soit inexistante, soit réaliser pas des analyste expert qui ont jamais écrit un programme de leur vie. Le genre d'analyse qui vous oblige à refaire son travail. Et j'ai même connu une société (pourtant très orienté IT) ou les développeurs se faisaient vraiment dénigrer pas la hiérarchie. Quand vos analystes ou vendeur commence a parler de vous en tant que pisseur de code c'est mauvais signe. J'ai connu des managers qui pour vous motiver vous disent qu'il faut faire du code de qualité et rapidement à la fois et qui ne comprennent pas qu'il y a un choix a faire et qui ne font pas ce choix. Trop facile...

Et effectivement il y a beaucoup de développeurs, architectes qui se complaisent dans ce système parce que finalement on est quand même bien payé et faire et défaire et refaire c'est toujours travailler. Puis aujourd'hui vous serez mieux payer si vous tenez un bon blog que si vous êtes vraiment un bon développeur.

[B413-151015]

Si les commerciaux arrêtais d'imposer des dates de sorties déjà, on aurais des produits moins buggé a leurs sorties.

(...)

Cela dit, il y'a aussi un autre facteurs a prendre en compte, les logiciels se sont aussi énormément complexifié par rapport à avant.

(...)
on peut avoir de très mauvaise surprise.

Oui c'est vrai. Beaucoup de développeurs ont oubliés KISS. On se retrouve avec des structures qui prônent les non dépendances et les interfaces à gogo à un point qu'on s'y perd. Oui SOLID c'est important mais ce reste moins important que KISS. A force de vouloir faire du développement SOLID (qui ne sera d'ailleurs jamais à 100% SOLID c'est impossible) on fini par complexifier le code tout en ne respectant pas vraiment SOLID puisque il est impossible de savoir ou se situe un code vraiment SOLID.

[Matthieu Vergne]

Oui c'est vrai. Beaucoup de développeurs ont oubliés KISS. On se retrouve avec des structures qui prônent les non dépendances et les interfaces à gogo à un point qu'on s'y perd. Oui SOLID c'est important mais ce reste moins important que KISS. A force de vouloir faire du développement SOLID (qui ne sera d'ailleurs jamais à 100% SOLID c'est impossible) on fini par complexifier le code tout en ne respectant pas vraiment SOLID puisque il est impossible de savoir ou se situe un code vraiment SOLID.

KISS c'est bien, mais ça ne suffit pas. J'ai entendu dire que c'était de Knuth :
1. make it works
2. make it right
3. make it fast

KISS, ça se limite au point 1. C'est par là qu'il faut commencer, mais si on s'y arrête on finit par accumuler des bouts simples qu'on agence ensuite comme on peut mais qui finissent par faire un ensemble compliqué car non homogène. SOLID concerne le point 2 et l'optimisation le point 3. Ce n'est pas incompatible, ça va ensemble. Faire que le premier est une hérésie sur le long terme (on finira par devoir tout refaire depuis zéro), faire que le second/troisième l'est sur le court terme (on n'est pas prêt de sortir quoi que ce soit). Il faut faire les deux, et dans l'ordre.

[Golgotha]

Bonjour,

Bien sûr que oui, les logiciels sont en grande majorité truffé de bug, mais les causes sont tellement nombreuses que ça va être difficile d'avancer.

- Tout d'abord, le coût de développement. Les clients cherchent la rapidité, la rentabilité : Comment voulez vous développez un site web ou une application pour 500 € dans les règles de l'art. Soyons sérieux, Ce n'est tout simplement pas possible.
- La formation. Aucune école ne forme correctement au métier de développeur, pire, on peux obtenir un équivalent bac+3 en suivant quelques tutoriel sur un site que je ne nommerai pas.
- Le temps. Ne compter pas le double ou le triple de temps mais bien plus entre le développement d'une application "à l'arrache" et l'autre "dans les règles".
- Les compétences. Réunir toutes les compétences nécessaires à la construction d'une application ou d'un site web requière énormément de temps et d'argent.
- Les technologies. Vous avez tout fait dans les règles de l'art, votre projet vous à couté 200K€, finalement une librairie open source était complétement bancal... pas de bol.
- l'art en lui même. Je considère le développement comme un art à part entière, ou comme un métier artisanal si vous préférez, et je pense que cet "art" est très jeune, c'est un art numérique, et comme les peintres, les cordonnier, les ébénistes, il nous faudra du temps pour élever cet art au même rang que les autres.

Bref, j'ai dans l'idée que ce n'est vraiment pas près de changer. Personnellement j'ai juste l'impression de vivre le début d'un art nouveau, comme les premiers hommes qui ont commencé à tailler des pierres, ou peindre dans une grotte. Le métier va surement beaucoup changer, se formaliser, se professionnaliser et perdre de toute cette magie comme le fait actuellement internet... Le jour ou il n'y aura plus ce "bordel", ce "chaos", certes les logiciels seront "propre", mais je serais surement un peu triste au fond...

[ec]

Dans tous les domaines, notamment politique au sens large, on assiste au même problème. Demandez-vous pourquoi la France s'est autant impliquée avec les génocidaires du Rwanda ? Une simple transposition de cette analyse permettrait de répondre en grande partie à cette question... et on a d'ailleurs entendu en 2010 Sarko parler "d'aveuglement" français au Rwanda. Mais ce n'est pas spécialement français. N'a-ton pas parlé du logiciel Volkswagen ces temps-ci ? N'était-ce pas pour résoudre un problème à court terme au lieu de bucher sur de bons systèmes de propulsion ? Et si je reviens à la France et son handicap à entrer de plein pied dans la transition énergétique ? Ou à la réforme des collèges qui affole le corps enseignant parce que les enseignants ne voient pas comment ils vont faire ? Ils ne voient pas... c'est bien le problème !

[DonQuiche]

KISS c'est bien, mais ça ne suffit pas.

Il n'a pas prétendu que ça suffisait mais que trop de développeurs l'avaient oublié. Et il a raison : beaucoup de programmes sont complexifiés pour de mauvaises raisons. Bien sûr tu n'as pas toujours le choix, parfois il faut sacrifier la simplicité, mais un programmeur devrait d'abord chercher ce qu'il peut élaguer et si telle ou telle source de complexité est vraiment nécessaire.

Plus simple, plus simple, plus simple.

Dans tous les domaines, notamment politique au sens large, on assiste au même problème. Demandez-vous pourquoi la France s'est autant impliquée avec les génocidaires du Rwanda ? Une simple transposition de cette analyse permettrait de répondre en grande partie à cette question... et on a d'ailleurs entendu en 2010 Sarko parler "d'aveuglement" français au Rwanda. Mais ce n'est pas spécialement français. N'a-ton pas parlé du logiciel Volkswagen ces temps-ci ? N'était-ce pas pour résoudre un problème à court terme au lieu de bucher sur de bons systèmes de propulsion ? Et si je reviens à la France et son handicap à entrer de plein pied dans la transition énergétique ? Ou à la réforme des collèges qui affole le corps enseignant parce que les enseignants ne voient pas comment ils vont faire ? Ils ne voient pas... c'est bien le problème !

Tout comme le développeur logiciel ne voit lui aussi qu'un petit bout de la lorgnette. Demande-toi donc tout ce que tu ne vois pas. Et vu cet inventaire à la Prévert, je dirais beaucoup.

[Matthieu Vergne]

Il n'a pas prétendu que ça suffisait mais que trop de développeurs l'avaient oublié.

Effectivement. C'est son KISS > SOLID qui m'a fait tiquer.

[abriotde]

Le logiciel qui marche est celui qui evolue par petite touches successives. Certes parfois il faut reprendre le coeur mais seulement lui et progressivement. Or aujourd hui on change de prestataire et il impose alors sa techno et n a pas le droit de regard sur l exisrant. Ca coute pour rien...