En tant que développeur, vous avez certainement déjà senti la nécessité de coder rapidement. Le plus souvent, cela se produit lorsque les délais sont très serrés et que vous sentez que vous ne serez pas en mesure de fournir un livrable attendu à temps. Mais parfois, ce comportement peut s’avérer très coûteux.C’est le cas par exemple si la pression d’aller vite vous amène à sous-estimer le travail à faire ou à mal l’évaluer, ne pas respecter la conception, les règles de codage, etc. Une complexité cachée découverte plus tard vous conduit alors à revenir en arrière. Ainsi, la volonté d'aller plus vite vous aura tout simplement fait prendre du retard.
À l'inverse, vous arrivez à terminer le projet dans les délais, mais avec une forte dette technique. Il faut en effet rappeler que dans un projet, la qualité augmente la charge de travail, ce qui peut avoir un impact sur le délai immédiat. Ainsi, lors de la survenue imminente d'une nouvelle version d'un logiciel par exemple, respecter la conception idéale peut mettre en péril la livraison d'une nouvelle version du logiciel. À ce moment précis, ne pas respecter la conception idéale peut permettre d'atteindre l'objectif prioritaire à court terme (sortir une nouvelle version), mais vous contractez une dette technique que vous allez rembourser tout au long de la vie du produit sous forme de temps de développement de plus en plus long et de bogues de plus en plus fréquents.
La solution serait donc d’aller lentement mais sûrement ? Une chose est sure, cela va permettre d’éviter les pièges ou limiter les erreurs. Dans un billet de blog sur Programmerfu.com, Garrett Lancaster, créateur d'une application SaaS, essaie d'ailleurs d'expliquer qu'en programmation, « aller lentement, c'est aller plus vite », ce que beaucoup d'entre nous ne mettront peut-être pas en doute. Il faut donc « ralentir pour être un programmeur meilleur et plus heureux », a-t-il suggéré dans une discussion sur Reddit.
Il explique que cela ne sera pas seulement bénéfique pour le développeur lui-même, mais aussi pour les autres développeurs qui auront à travailler sur son code, que ça soit pour ajouter de nouvelles fonctionnalités ou pour le maintenir. Il n’est en effet pas nécessaire de rappeler comment cela peut être pénible de travailler sur un code de mauvaise qualité, et en plus écrit par une autre personne. Mais dans la réalité, vu les contraintes extérieures, la suggestion de Garrett Lancaster est-elle applicable ? Cela s'aligne-t-il avec la vision de l’entreprise et du management ? C'est sur ce point que la suggestion de Garrett Lancaster a été débattue.
Le fait est que le plus souvent, c’est l’entreprise et le management qui créent un environnement sous pression avec des délais très serrés obligeant les équipes de développeurs à essayer d’aller le plus vite possible. Il faut donc avant tout les persuader que cette manière de travailler peut affecter la qualité du code et pourrait nécessiter plus de travail plus tard. Pour un développeur qui essaie d’aller lentement pour éviter de commettre des erreurs graves, comment sera-t-il perçu par son manager ou son entreprise ? Comme quelqu’un de paresseux, sous-performant, non motivé ?
Et vous ?
Qu'en pensez-vous ? 
.
Envoyé par foetus
