Discussion :

[Bill Fassinou]

Les développeurs sont-ils trop lents pour innover ou pour déployer de nouvelles fonctionnalités ?
la chasse aux bogues, les petites équipes et les limites budgétaires en seraient quelques causes

Une récente étude réalisée par la société de logiciels Rollbar a révélé que bien souvent, les développeurs voudraient innover ou déployer plus rapidement de nouvelles fonctionnalités, mais voient leurs prévisions bouleversées par certaines contraintes. L'étude, menée auprès de 950 développeurs, a révélé que 84 % des équipes étaient empêchées de déployer plus fréquemment un nouveau code en production en raison de contraintes comme : la recherche de bogues, des équipes et des budgets très réduits, etc. Elle révèle en outre que seulement 25 % arrivent à déployer du nouveau code en production chaque mois ou tous les deux mois.

« Les développeurs veulent avoir une idée, l'écrire dans le code et faire en sorte que l'utilisateur vive cette idée », explique le cofondateur et directeur technique de Rollbar Cory Virok. « Mais la réalité est que le code qui est censé offrir ces expériences est souvent truffé d'erreurs et de bogues. Afin d'offrir une expérience client exceptionnelle, les développeurs consacrent jusqu'à 40 % de leur temps aux tests et à l'assurance qualité. Pourtant, les logiciels ne sont jamais parfaits, et la recherche de la perfection constitue un obstacle à l'itération et à l'innovation », a-t-il continué.

En effet, les résultats de l'étude ont révélé que 84 % des équipes étaient empêchées de déployer plus fréquemment un nouveau code en production. La principale raison invoquée par les développeurs pour expliquer ces retards est le test et l'assurance qualité. Plus d'un tiers (36 %) des personnes interrogées ont déclaré que la difficulté de trouver et de corriger les erreurs en production les ralentissait. Un quart (25 %) des développeurs ont déclaré qu'ils ne déployaient du code que tous les mois ou tous les deux mois, tandis qu'environ 22 % ont dit qu'ils lançaient du nouveau code toutes les deux semaines.

Environ 6 % ne déploient du nouveau code que deux fois par an. Comme souligné par Virok, Rollbar a constaté qu'au total, les développeurs consacrent jusqu'à 40 % de leur temps aux seuls tests et à l'assurance qualité, un temps qui aurait pu être utilisé pour itérer sur leur code et pour lancer de nouvelles fonctionnalités. En outre, des recherches antérieures de Rollbar ont mis en évidence la difficulté pour les développeurs d'essayer de détecter les bogues avant que leur logiciel n'atteigne la phase de production. Cette nouvelle étude réalisée en février montre que cette difficulté retarde toujours les équipes de développement.

Selon le rapport de l'étude, 88 % des développeurs estiment que les outils traditionnels de surveillance des erreurs ne sont pas à la hauteur, et que la détection des bogues et des erreurs leur prend trop de temps. Cela dit, les processus techniques ne sont pas les seuls à blâmer. Près d'un tiers (30 %) des personnes interrogées ont déclaré que leur équipe était trop petite pour permettre des déploiements plus fréquents. Les restrictions budgétaires ont été mises en cause par 16 % des répondants, tandis que 15 % ont déclaré que leur organisation s'appuyait sur des "méthodologies traditionnelles".

Selon ces derniers, ces méthodologies « ne correspondent pas à leurs plans de développement ». D'après environ 13 % des répondants, leur organisation s'appuie sur une gestion de projet imprécise. Par ailleurs, un dixième des personnes interrogées par Rollbar ont déclaré que le manque de leadership les empêchait d'innover plus rapidement, et 9 % ont déclaré que leurs ambitions étaient freinées par l'absence de vision à long terme au sein de leur organisation. Holger Mueller, vice-président et analyste principal chez Constellation Research, a déclaré que le fait d'essayer de perfectionner le code se fait souvent au détriment de l'innovation.

Selon ce dernier, cela constitue un inconvénient majeur dans le monde hautement concurrentiel du développement de logiciels. « Les organisations qui s'appuient sur des logiciels, c'est-à-dire toutes les organisations, doivent introduire et itérer sur le code rapidement pour être compétitives », a déclaré Mueller. « Ce n'est pas facile. Les développeurs se retrouvent souvent coincés dans les méandres du code à perfectionner. Mais les nouveaux outils permettent désormais aux développeurs de faire plus de releases plus souvent », a-t-il ajouté.

En somme, l'enquête de Rollbar a révélé que la majorité des programmeurs se languissaient d'un moyen plus rapide d'éliminer les bogues dans le code. Deux cinquièmes (40 %) des personnes interrogées ont déclaré vouloir de meilleurs outils pour détecter et corriger les erreurs de code. Près d'un tiers ont déclaré qu'une meilleure gestion de projet (38 %), une équipe plus importante (36 %) ou un budget plus élevé (30 %) leur donneraient confiance et leur permettraient de lancer de nouvelles fonctionnalités plus rapidement.

Parmi les 86 % de développeurs qui ont déclaré que de nouvelles capacités les aideraient à itérer plus rapidement, nous avons :

• 47 % ont déclaré que le fait de voir l'origine de chaque erreur accélèrerait ces efforts ;
• 34 % ont déclaré que les capacités de détection de bogues en temps réel permettraient d'améliorer plus rapidement le code ;
• 33 % ont déclaré que l'accès à des informations contextuelles riches sur chaque erreur serait bénéfique ;
• 33 % ont déclaré que les nouvelles capacités d'aide à l'assurance qualité permettraient une itération plus rapide ;
• 22 % ont déclaré qu'un accès ouvert aux API leur permettrait d'accélérer l'itération.

« Il n'est pas surprenant que les entreprises souhaitent des logiciels de haute qualité qui offrent aux utilisateurs la meilleure expérience possible. Mais les logiciels sont constitués de code, et un code sans erreur est un leurre », a déclaré Brian Rue, PDG et cofondateur de Rollbar. « Les entreprises de premier plan adaptent leurs outils, leurs mentalités et leurs comportements pour faire face à cette réalité. Au lieu d'essayer de perfectionner les logiciels, elles adoptent de meilleurs outils et processus pour découvrir de manière proactive les erreurs lorsqu'elles se produisent et les résoudre immédiatement ».

Rollbar est une entreprise qui met à la disposition des développeurs une plateforme d'amélioration continue du code qui découvre, prédit et corrige les erreurs de manière proactive grâce à des flux de travail assistés par l'IA en temps réel. Rollbar s'est donné pour mission d'aider les développeurs à améliorer continuellement leur code et à innover constamment plutôt que de passer du temps à surveiller, enquêter et déboguer.

Source : Rapport de l'étude de Rollbar

Et vous ?

Que pensez-vous des conclusions de l'étude de Rollbar ?
Votre organisation a-t-elle des difficultés pour déployer plus fréquemment de nouvelles fonctionnalités ?
Comment pensez-vous que les équipes pourraient améliorer leur fréquence de déploiement de nouveau code ou d'innovation ?

Voir aussi

Agile pourrait-il conduire les organisations vers une dette technique plus importante ? Oui, selon Don Clos, développeur logiciel, qui propose une analyse détaillée de la situation

Code Defect AI, un outil IA pour aider les développeurs à repérer les bogues pendant le codage et non à la fin, disponible en open source sous licence Apache v2.0

Google rend disponible en open source ClusterFuzz, une infrastructure de test à données aléatoires, fonctionnant sur plus de 25 000 cœurs

Projet Springfield : Microsoft veut aider les développeurs à détecter les bogues de sécurité, en recourant au cloud et à l'intelligence artificielle

Suivi des linters JavaScript, outils d'analyse statique de code source, ESLint en 4.19.0 et standardJS en 11.0.0

[MysticKhal_0]

Le kébabier est-il trop lent pour faire le kebab ? La faute aux lois de la physique !

[darklinux]

Et pourquoi pas ? Il faut normaliser la chose , pour ne pas réinventer la roue

[ddoumeche]

Déployer du code simple en production tous les mois c'est facile mais ne dure qu'un temps.

Déployer une application complexe en production tous les mois réclame de gros moyens, notament une personne chargée de la recette ... qui devrait idéalement être intégrée à l'équipe de dev pour racourcir les délais. Donc il vous faut des springs toujours à l'heure, des nouvelles fonctionalités simples, des test unitaires parfait, des fonctionnalités non bugués, une planification sans faille avec la Q/A, et une mise en production immédiate.

Aussi la plus sure option pour livrer à temps est bien sur de virer la QA et de se passer d'Agile dans les premières phases de conception (vu que personne ne sait évaluer le temps nécessaire).
Sinon je vous souhaite bien du courage sauf si vous ne faites que de la Tierce Maintenance Applicative.

[smarties]

Le client demande généralement : je le veux le plus vite possible sans que ça me coute un bras
J'ai donc rarement le temps de faire des tests unitaires et je suis loin de tester tous les cas. Les gens en recette fonctionnelle testent plus mais des bugs passent à travers.

En plus quand une société édite un logiciel qui est personnalisé plus ou moins en fonction des clients, cela devient compliqué de proposer des améliorations. Le service maintenance doit suivre

[TotoParis]

J'hallucine pas mal, là. Les développeurs ne décident de rien. Ils sont au bas de l'échelle. C'est le client qui est en haut.
C'est son budget qui paie tout. Les "nouvelles fonctionnalités", c'est au client de décider. Pour le reste (sécurité, performances, ertc...) c'est
au fournisseur de proposer. Mais le code reste la propriété du client.
Quand je lis "J'ai donc rarement le temps de faire des tests unitaires et je suis loin de tester tous les cas', là aussi j'hallucine :
c'est qui le responsable en cas de problème ? De mon point de vue, le client. Mais merci la bataille juridique en cas de pertes
financières.
Une dernière chose, hélas souvent vérifiée en informatique : le mieux est l'ennemi du bien.

[kilroyFR]

C'est exactement ce qu'on vit au quotidien. On est passé il y a quelques années en archi micro services; deploiements chirurgicaux etc. sauf qu'en realité c'est pas du tout ca, mais c'est meme plutot pire qu'avant comme tout est interdependant, il faut penser a tout redonder, a le faire dans un certain ordre et comme l'archi est distribuée et complexe, les gens tremblent quand on doit faire une MAJ en prod, la peur d'avoir oublié quelque chose ou pas fait dans le bon ordre.
Et ca se verifie, 9 fois sur 10 on a des problemes. Avant on faisait un bug dans un logiciel dans un coin ca ne genait personne, maintenant quand un bug survient c'est toute la plateforme qui deconne.
Dans le meilleur des cas on trouve et on resoud rapidement le soucis; en pratique malgré notre ELK et nos tonnes de logs, quand ca merde, on pleure a comprendre le pourquoi du comment. Sur la papier pourtant c'etait plus simple, la realité est bien differente. On etait bien plus efficace quand nos applis etaient dite "monolithiques" (alors que ce n'etait pas vrai puisqu'elles etaient en couches); maintenant on se retrouve avec une archi monolithique dans le sens ou on flippe avant chaque mise en prod (malgré les tonnes de TU pourtant). Pas certain que ce soit un progres.

Bon apres ce sondage ne vaut rien, fait par une boite qui vend un logiciel qui remplit comme par hasard la fonction tant attendue par nos chers developpeurs. C'est du marketing deguisé ca n'a aucune valeur.

[tanaka59]

Bonsoir,

Les développeurs sont-ils trop lents pour innover ou pour déployer de nouvelles fonctionnalités ?

La lenteur a plusieurs facteurs :

> un informaticien utilise sa pensée intellectuelle / pensée cérébrale , penser et réfléchir demande du temps ... La logique n'est pas instantanée ! L'humain se fatigue ... Sans parler de la charge mentale et intellectuelle .
> facteur financier (forcement si un budget est ridicule , le projet évolue peu ...)
> facteur temps (demander 1 semaines pour un projet qui demande 3 semaines ... forcement on cumule carence de développement, sur carence )
> facteur humain (quand on a pas assez de personnel ou que celui ci n'est pas assez qualifié)
> facteur organisationnel (quand on est face à des services qui donnent des instructions contradictoires, c'est du déjà vu !)

Comment pensez-vous que les équipes pourraient améliorer leur fréquence de déploiement de nouveau code ou d'innovation ?

C'est propre a chaque entreprise. Cela demande que l'entreprise sache se remettre en question, sur les facteurs précités. Ce qui est rarement le cas ... D’où des situations ou l'on persiste dans la bêtise.

[Pyramidev]

HS microservices : @kilroyFR, pourtant, je me rappelle que, il y a deux ans, tu étais à fond en faveur des microservices. Entre temps, je vois que tu as vécu une désillusion.

J'en profite pour partager un dialogue intéressant de 2020 entre Martin Fowler et Sam Newman : When to Use Microservices (And When Not To!)

La vidéo :

La retranscription : https://gotopia.tech/bookclub/episod...-martin-fowler

[el_slapper]

Bon, je vais faire la voix de la QA. La QA "ne va pas assez vite". Effectivement, il peut parfois falloir du temps pour trouver un bug, voire pour le reporter.

Une des difficultés qu'on a, c'est que quand un test automatique (coté interface, pas coté API, ceux-là sont généralement la came des développeurs) plante, plein de causes peuvent être possibles, et il faut du temps pour trouver ce qui a réellement planté. Souvent, el bug est bien en amont de ce qui plante.

Mais aussi, une fois qu'on a identifié le big, il faut prendre le temps de définir son périmètre, sa dynamique exacte. Presque à chaque fois que j'ai voulu aller trop vite dans la rédaction du bug, le truc m'est revenu dans la tronche avec un bug partiellement corrigé. Donc si j'ai une erreur d'arrondi sur le calcul de dose lors d'une intraveineuse continue, je vais me mettre à vérifier systématiquement tous les calculs similaires (intraveineuse discontinue, cathéters, etc.) qui pourraient avoir le bug. Ca prend du temps. Ca prend du temps, mais ça évite de tuer des gens (le cas est authentique, j'ai eu ça en octobre 2017).

Il y a des choses qui s'automatisent bien (typiquement, le bug ci-dessus a été trouvé par des tests automatiques d'interface, qui cherchaient juste à vérifier si le point marchait aussi bien que la virgule. On trouve rarement ce qu'on cherche, en QA, et c'est ça qui est rigolo). Et même celles là peuvent parfois prendre du temps avant de pondre un rapport de bug exploitable par les développeurs. D'autres beaucoup moins bien - spécialement l'ergonomie - et il faut du temps pour vérifier tout ça.

Je dirais à vue de nez que le rapport est 85/15. 85% des problèmes sont détectables par des automatismes (qui sont parfois très couteux, un test d'interface est beaucoup plus long à automatiser qu'un test d'API, principalement pour des raisons de temps d'exécution). Les 15% restants sont souvent des avantages compétitifs.