Un développeur estime que nous vivons dans l'âge des logiciels ratés
Et l'explique par les antipatterns et pratiques d'aujourd'hui

Le , par Michael Guilloux, Chroniqueur Actualités
Il arrive souvent de trouver au sein des entreprises des logiciels développés par des ingénieurs censés être compétents, et pourtant qui laissent beaucoup à désirer. D’après un développeur, ce n’est pas parce qu’il manque de développeurs techniquement compétents, mais c’est simplement dû au fait que nous vivons dans l’âge des logiciels ratés, où les entreprises et le management sont ceux qui décident de la qualité des logiciels. En se basant sur du vécu, le développeur a dressé une liste d’anti patterns et mauvaises pratiques dans l’environnement actuel de développement de logiciels, qui conduisent à des logiciels de mauvaise qualité. Il situe le problème au-delà des compétences techniques, et le considère comme résultant de la vision de l’entreprise, du management ou encore la mentalité des développeurs eux-mêmes.

Le premier problème est que les entreprises et le management ont une vision à court terme. Comme l’explique le développeur, le monde des affaires actuel est plein d’incertitudes, ce qui conduit les entreprises à limiter la portée de certaines décisions au court terme. Malheureusement, les entreprises essaient d’appliquer cela également dans le développement de logiciels. « Plus votre logiciel peut être pensé sur le long terme, plus le développement sera robuste, économique et sans douleur », explique-t-il. Mais le management sacrifie l’intégrité de votre système logiciel avec ses prises de décisions « myopes », qui ne voient que le futur proche.

Vous devez être alignés sur le même point de vue que la direction, c’est le plus important. Ensuite, vous devez aider la direction à atteindre ses objectifs pour le prochain trimestre. « Cela signifie que la plupart de votre temps sera consacré à la lutte contre les incendies provoqués lors des trimestres précédents, la chasse aux bugs qui auraient pu être facilement évités ou refactoriser plusieurs morceaux de code indépendants, juste pour mettre en œuvre la prochaine fonctionnalité à problème ».

Si vous êtes architecte de logiciels, construire un système cohérent, compréhensible et bien conçu ne devrait pas être votre priorité. Votre mission sera de satisfaire la vision à court terme du management. Ce qui conduit à négliger une conception viable à long terme pour produire un système qui satisfait les besoins immédiats, tout en compromettant ceux à venir.

Un point mis en avant par le développeur est que vous n’êtes pas payés pour résoudre les problèmes, mais pour les endurer. L’essentiel, c’est qu’avec les codes existants qui sont remplis de bugs, vous puissiez arriver à un semblant de progrès.

Si les entreprises et le management sont myopes, vos collègues sont les seuls pour qui cela n’est pas un problème. « Alors que votre manager ne peut penser au-delà de la prochaine période de reporting, vos collègues ne peuvent probablement pas penser au-delà de la prochaine période de paie », explique-t-il. Tant que l’objectif premier de ces derniers - le salaire - est garanti, ils sont prêts à accepter n’importe quelle décision, et pour eux, le système tourne à merveille, pourquoi devrait-il donc changer ?

Si vos collègues pensent à la prochaine période de paie, il y en a probablement un dans le groupe qui a déjà ajusté ses habitudes de consommation à sa prochaine promotion. Selon le développeur, il s’agit en général de celui qui va remplacer l’architecte ou le lead. Se considérant comme le meilleur du groupe, il ne perd pas son temps dans les discussions inutiles. Il a la meilleure idée, s’il la propose et que vous ne la saisissez pas, tant pis ! « C’est le gars assis en face de vous qui ne se plaint jamais du code, qui ne perd jamais son temps pour nettoyer les choses, et qui est toujours le premier à arrêter la discussion ‘toxique’».

Le développeur regrette également l’introduction de la propriété collective du code. Il s’agit d’un principe de l’eXtreme Programming qui stipule que « chaque développeur doit pouvoir modifier toutes les parties du code si le besoin s'en fait sentir ». Pour lui, il peut être très avantageux que la modification du code soit un droit exclusif à certains développeurs. Il plaint donc la disparition d’un système où seuls les ingénieurs seniors avaient le droit de modification du code. Cela permettait en général de protéger le code contre les visions de court terme et contre « une équipe de management qui n’est pas en mesure de comprendre ou d’en apprendre davantage sur les compromis au jeu de l’ingénierie ». Ce système permettait de garantir également que le logiciel soit développé à un rythme durable avec le minimum de souffrances humaines. Malheureusement, il ne peut plus subsister avec la propriété collective du code.

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.

Source : Medium

Et vous ?

Qu’en pensez-vous ? L’environnement moderne de développement de logiciels est-il moins favorable à la conception de bons logiciels ?

Voir aussi

Forum ALM

Forum Général Développement


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de RyzenOC RyzenOC - Membre extrêmement actif https://www.developpez.com
le 13/10/2015 à 15:53
Le principal problème c'est plus le temps de dev pour un projet, plus les délais sont serrés plus c'est difficile de faire du bon boulot.
Avatar de lankoande lankoande - Membre confirmé https://www.developpez.com
le 13/10/2015 à 15:53
C'est tout à fait juste ! Mais la solution c'est laquelle ?
Avatar de DarkHylian DarkHylian - Membre habitué https://www.developpez.com
le 13/10/2015 à 16:08
Pour ma part, ça ressemble bien à ce que je vis.
Et je vais me permettre une analogie :
Un excellent musicien perdra plus de temps à retoquer sa partition et sa maitrise de l'instrument pour arriver à produire le son "parfait" qu'il veut atteindre. Les maisons de disques sont juste là pour faire du fric rapidement.

De la même manière, le développement logiciel est un art théorique, et le monde de l'entreprise s'en sert comme d'une simple matière première...

Avec le temps, la vision financière des entreprises s'est malheureusement accrue, et du coup, on essaye de faire en sorte que la matière première devienne un produit fini plus rapidement, et tant pis si la qualité ne le fait tenir que quelques années (voire mois).
C'est pire que l'âge du logiciel raté, c'est l'âge du code poubelle... vive la société de conSOMMATION.
Avatar de JackJnr JackJnr - Membre confirmé https://www.developpez.com
le 13/10/2015 à 16:14
Citation Envoyé par DarkHylian Voir le message

De la même manière, le développement logiciel est un art théorique, et le monde de l'entreprise s'en sert comme d'une simple matière première...
C'est malheureusement vrai dans beaucoup d'autres domaines. Si encore nous pouvions avoir une vision a minima moyen-terme ce serait un grand pas fait en avant. Je pense que beaucoup d'entreprises ont les moyens de se le permettre.
Avatar de Sodium Sodium - Membre éprouvé https://www.developpez.com
le 13/10/2015 à 16:21
"Bonjour, je suis représentant de commerce en enfonceurs de portes ouvertes... ah, je vois que vous êtes déjà très bien équipés, je ne vous embête donc pas plus !"
Avatar de PierreMF PierreMF - Futur Membre du Club https://www.developpez.com
le 13/10/2015 à 16:56
Il y a encore quelques sociétés où l'on a encore le goût de l'architecture avant le codage, où les specs existent, où l'on prend le temps d'avoir une vision à plus long terme.

Ce n'est peut-être pas la majorité, mais cela existe, et ce n'est pas si rare que ça. Alors si vous cherchez une mission ou un emploi, prenez le temps lors de l'entretien de vous renseigner sur les méthodes de management et de développement. Vous ne le regretterez pas !

La méthodologie agile est des fois utilisée pour fliquer et presser les développeurs, et correspond parfois à cette courte vue, mais ce n'est pas toujours le cas.

Le taux de turnover de la boîte est un élément important : si les gens ne restent pas longtemps, c'est généralement le cas d'une boîte décrite dans l'article. Si par contre les gens restent longtemps, c'est qu'ils s'épanouissent dans leur travail.

"Soyez le changement que vous voulez voir dans le monde" - Gandhi
Avatar de Anne Au Nîmes Anne Au Nîmes - Futur Membre du Club https://www.developpez.com
le 13/10/2015 à 17:12
Citation Envoyé par Sodium Voir le message
"Bonjour, je suis représentant de commerce en enfonceurs de portes ouvertes... ah, je vois que vous êtes déjà très bien équipés, je ne vous embête donc pas plus !"
+1

Blablabla
Avatar de dun74fr dun74fr - Futur Membre du Club https://www.developpez.com
le 13/10/2015 à 17:15
Désolé d'aller à contre courant, mais cela me parait une vision totalement obsolète du développement informatique.
En effet le marché a changé, en effet il faut faire vite, mais ce serait suicidaire pour une entreprise de pratiquer autrement.
On peut faire du bon logiciel en ayant une vision itérative et à court terme des besoins. De toute façon personne n'est medium et pourra prédire les futures évolutions du logiciel ou du marché.
J'ai assez travailler avec des personnes voulant tout prévoir pour savoir que le résultat est loin d'être meilleur. On se retrouve avec des pans entiers de code inutiles, compliqués et non maintenable.
La clé est de savoir casser, réécrire et redesigner en fonction des évolutions et ne pas empiler les couches de code.
Malgré les mots "casser" et réécrire, le coût final du projet ne sera pas plus gros qu'un design "je prévois toutes les évolutions possibles". Le code restera à jour et moderne.
Perso je suis pour écrire du code qui fonctionne, ne pue pas, et fait ce qu'il doit faire maintenant et pas dans 2 ans.
Avatar de foetus foetus - Expert confirmé https://www.developpez.com
le 13/10/2015 à 17:19
Citation Envoyé par PierreMF Voir le message
Si par contre les gens restent longtemps, c'est qu'ils s'épanouissent dans leur travail.
Par forcément
Une bonne paye, pas trop de pression/ responsabilités, de bons horaires et le tour est joué.

Et si en plus la société a des avantages c'est "la patate de bonheur": CE, café gratuit, ...
Avatar de 4sStylZ 4sStylZ - Membre éclairé https://www.developpez.com
le 13/10/2015 à 17:51
Le développeur regrette également l’introduction de la propriété collective du code. Il s’agit d’un principe de l’eXtreme Programming qui stipule que « chaque développeur doit pouvoir modifier toutes les parties du code si le besoin s'en fait sentir ». Pour lui, il peut être très avantageux que la modification du code soit un droit exclusif à certains développeurs. Il plaint donc la disparition d’un système où seuls les ingénieurs seniors avaient le droit de modification du code. Cela permettait en général de protéger le code contre les visions de court terme et contre « une équipe de management qui n’est pas en mesure de comprendre ou d’en apprendre davantage sur les compromis au jeu de l’ingénierie ». Ce système permettait de garantir également que le logiciel soit développé à un rythme durable avec le minimum de souffrances humaines. Malheureusement, il ne peut plus subsister avec la propriété collective du code.
Ya que moi que ça remue ce genre de paragraphe?

En synthèse, ce mec prône la rétention d'info et de connaissances. Ça colle pas trop à l'idée de voir à plus long terme tout ça.

J'ai eu quelques fois des «seniors» qui s'accaparait de certains modules dans chaque projet car bon c'est eux qui les avaient conçus donc bon c'est plus facile comme ça parce qu'ils ont l'éxpérience.
Ça donne un super code en dehors de tout standards. Un code pensé par un seul cerveau «de génie» mais qui un jour se barrera élever des chèvres en Bretagne.

L'aboutissement dans cette propriété personnelle du code?*Une équipe remplie de mecs «moyens», des nazes en somme, qui devra ouvrir… TADAA : la boite de Pandore!
Contacter le responsable de la rubrique Accueil