Dette technique croissante dans les petites sociétés de logiciels indiennes développant des applications et des sites Web : qui en est responsable ?

Je travaille dans l'industrie indienne des services logiciels depuis 10 ans maintenant et pendant tout ce temps, j'ai vu de bons projets se terminer et faire des merveilles. J'ai vu des équipes squelettiques travailler sans relâche dans des conditions angoissantes pour créer des produits qui ont été appréciés par des personnes à l'autre bout de la planète. Et bien qu'il y ait eu de bons souvenirs au cours de cette décennie de travail sur de merveilleux projets, j'ai également été témoin de projets qui se dégradent et de produits logiciels qui se bâclent pour diverses raisons. Cela s'est produit plus de fois que je ne l'aurais souhaité autour de moi et autour de personnes que j'ai connues au cours de ces 10 années.

On a beaucoup parlé de projets qui tournent mal. Les mèmes envahissent Internet sur la façon dont toute la hiérarchie se poursuit comme une chaîne alimentaire dans la jungle. Certaines personnes reprochent aux programmeurs d'avoir écrit du code bogué, tandis que d'autres maudissent la direction pour avoir fait des promesses irréalisables et impossibles à tenir. Certaines personnes reprochent même aux clients de ne pas comprendre les prérequis techniques et les dépendances de cette industrie. Mais je n'ai entendu presque personne parler de dette technique ou de dette de code, et traiter ce problème de manière civilisée sans se pointer du doigt les uns les autres. Pas une seule fois je n'ai rencontré ce terme de Tech Debt des gens autour de moi, ou des événements auxquels j'ai assisté, ou des blogs locaux que j'ai lus.

Je ne suis tombé sur ce terme que lorsque j'ai lu des blogs et des revues de la Silicon Valley aux États-Unis. Cela signifie que la plupart des programmeurs et des responsables de logiciels travaillant dans des petites et moyennes entreprises de développement de logiciels en Inde n'auraient même pas entendu parler de ce terme jusqu'à présent. Alors, permettez-moi de commencer par expliquer le terme lui-même. La dette technique, ou dette de code, est un concept de développement logiciel qui reflète le coût implicite des retouches supplémentaires causées par le choix d'une solution simple (limitée) maintenant au lieu d'utiliser une meilleure approche qui prendrait plus de temps.

Permettez-moi de le décomposer pour le rendre simple. Il s'agit d'un concept permettant de calculer le coût de la résolution des problèmes de programmation et de conception qui auraient pu survenir en choisissant une option simple de construction d'un module particulier, ou d'un système entier, au lieu de choisir la méthode la meilleure et la plus efficace pour le construire. Dans le domaine du développement de logiciels, ce phénomène de votre paresse et de votre retard revenant vous mordre au cul se produit beaucoup plus souvent que partout ailleurs. C'est presque comme si Karma avait une représentation sociale d'être garce par les programmeurs.

S'il vous plaît, ne vous méprenez pas, je ne blâme pas toute la dette de code sur les programmeurs. Il existe certainement plusieurs entités responsables de la dette de code qui survient à coup sûr dans plus de 90% des projets des petites entreprises de développement de logiciels en Inde. Permettez-moi d'essayer d'en couvrir quelques-uns brièvement :

1. CLIENTS IMPATIENTS ET TROP INTELLIGENTS

Oui, je commencerai par mordre la main même qui nourrit et je le ferai sans pitié. Le marché des projets de développement de logiciels externalisés de petite taille est énorme et très fragmenté. Il y a de véritables bonnes entreprises qui justifient parfaitement ce marché mondialisé, tandis que d'autres ne sont que des entreprises parasites qui se nourrissent de cet arrangement parfaitement bon simplement parce qu'il est non réglementé et incontrôlé.

Cela conduit les clients à faire une erreur en choisissant la bonne entreprise avec laquelle s'associer en fonction de leurs besoins. Bien que ne pas avoir les compétences de vérification appropriées ne soit pas de leur faute, mais il n'y a personne à blâmer pour qu'ils n'aient pas l'intelligence de base de la rue pour identifier une entreprise d'ordures à partir d'une véritable. Maintenant, une fois qu'ils acceptent d'aller de l'avant avec une équipe sous-talentueuse, ils étouffent leurs attentes irréalistes et leur calendrier. De plus, certains d'entre eux vont même trop loin et montrent à quel point ils sont intelligents en apportant leurs propres suggestions en matière de conception et de programmation. (#pastouslesclients )

Si jamais vous êtes client d'une société de développement de logiciels, je vous demande humblement de les laisser faire et de leur permettre de faire leur travail. Essayez d'aller voir un médecin ou un avocat et dites-leur ce que vous avez cherché sur Google et ce qu'il a dit à propos de votre problème et voyez la réaction sur leurs visages. Aucun expert dans son domaine n'aime être conseillé sur son propre domaine par un noob. Les ingénieurs logiciels ne font pas exception.

Si vous trouvez une bonne équipe de développement de logiciels et qu'elle semble prometteuse, donnez-lui son espace et elle ne ressentira pas le besoin de prendre des raccourcis, ce qui réduirait la dette de code dans votre projet. Et devinez quoi, la plupart du temps, c'est vous les gars, les clients qui payez cette dette de code. Avez-vous déjà entendu parler des mots : "Demande de modification" ? Je parie que la plupart d'entre vous l'ont fait ! Dans un scénario idéal, vous ne devriez jamais entendre ces mots dans votre vie. Mais cela arrive rarement. Et plus vous entendez ces mots, plus vous vous trompez en étant client d'une société de logiciels.

2. GESTIONNAIRES PARESSEUX ET SOURDES

Quand je dis gestionnaires ici, c'est n'importe qui dans la position de gestion de projet du côté de la société de développement de logiciels. Qu'il s'agisse d'un chef de projet, d'un chef d'équipe, d'un chef de livraison ou d'un propriétaire d'entreprise, si vous avez déjà essayé de vous laver rapidement les mains d'un projet juste pour le conclure et percevoir votre paiement, vous êtes un parti également à blâmer dans cette Tech Debt qui s'accumule dans vos projets.

Bien que le plus triste ici soit que vous ne devez jamais payer la dette technologique qui s'élève. Soit c'est le client qui paie en utilisant un produit de qualité inférieure, soit en payant plus d'argent pour le faire nettoyer. Et si ce n'est pas le client, ce sont les pauvres programmeurs qui le paient en devant travailler des heures interminables bien au-delà de ce qu'ils sont tenus de faire. Mais ce ne sont presque jamais ces intermédiaires, donc selon moi, ils devraient être les entités les plus responsables dans ce sujet de la dette technologique.

Si jamais vous engagez l'un d'entre eux, la plus grande qualité qu'ils devraient avoir est la moralité. Si leur boussole morale pointe dans la bonne direction, ils prendront leurs responsabilités et prendront la bonne décision en faveur du projet, ce qui conduirait éventuellement à moins de compilation de dettes technologiques. Cela me rappelle cette célèbre citation de Jack Ma où il parlait de choisir de travailler pour le bon leader. Très approprié dans ce scénario ici.

3. PROGRAMMEURS

Oh ouais, je ne finirais pas ce sujet en vous blâmant aussi les gars! Mais bon, #notallprogrammers n'est-ce pas ? Eh bien, oui, mais près de 94% des programmeurs. C'est du moins ce que pense CP Gurani, PDG de Tech Mahindra, lorsqu'il a fait la révélation choquante il y a quelques années que 94 % des diplômés en informatique sont inaptes au travail. Je ne sais pas exactement comment il est arrivé à ce chiffre, mais étant un produit des écoles d'ingénieurs indiennes et ayant été témoin de l'ensemble de l'écosystème de l'ingénierie informatique au cours des 10 dernières années, je peux dire que j'ai tendance à être d'accord avec ce que M. Gurani a déclaré.

Je n'essaie pas de débattre si c'est 94 %, ou 90 %, ou 80 %. Mais pour vous donner une analogie, c'est comme si nous savions presque tous que nous avons besoin de farine, d'eau et d'une pincée de sel pour faire la pâte, et d'un rouleau à pâtisserie pour faire les chapatis. Mais très peu d'entre nous peuvent réellement faire des chapatis comestibles. C'est un processus extrêmement simple, mais qui nécessite tout de même un certain talent et des tonnes de pratique pour y exceller. Il en va de même pour la programmation. Nous connaissons tous la recette, mais très peu ont retroussé nos manches, se sont sali les mains et l'ont pratiquée aussi longtemps qu'il a fallu pour maîtriser ce métier.

Par conséquent, même lorsqu'un programmeur moyen est chargé d'un projet, il écrira sans le savoir du code avec une dette technologique intégrée qu'il ne réalisera que plus tard. Et si vous vous demandez comment l'industrie fonctionne globalement de manière positive avec la plupart des programmeurs inaptes au travail, c'est à cause de leurs managers efficaces et de leurs seniors expérimentés qui ont appris les choses à la dure. Ils aident ces mains et ces esprits neufs à naviguer sur les chemins dangereux de l'écriture de code optimal et rendent l'expédition du projet réalisable et le maintiennent à l'abri d'une dette pesante. Et finalement, avec une préparation et une formation appropriées, ces recrues deviennent bonnes dans leur travail, ou elles finissent par dire adieu à l'industrie informatique.

Donc, en conclusion, je pense que les 3 principales parties de cette collaboration doivent partager la responsabilité de la compilation de la dette de code. Encore une fois, ne considérez pas cette pièce comme une pièce démontrant tout ce qui ne va pas dans l'industrie. C'est comme n'importe quelle autre industrie dans le monde avec sa juste part d'horreurs et de héros. Même après 10 ans à faire ça, je ne ferais toujours rien d'autre de ma vie. J'aime ce travail, j'aime être une petite entreprise travaillant sur des projets passionnants pour des clients du monde entier.

L'objectif était de rendre les 3 parties prenantes plus responsables et de les familiariser avec cette perte sous-jacente qui leur était infligée par une mauvaise collaboration. Si une équipe de développement logiciel souhaite calculer et mesurer avec précision sa dette technologique, elle peut suivre un modèle de processus strict basé sur la méthodologie Agile, voire la méthodologie Waterfall. Lorsque vous suivez cette approche disciplinée, vous serez en mesure de marquer ces sprints de révision et de réparation séparément et à la fin d'une phase, vous serez en mesure de calculer précisément le nombre d'entre eux dont vous avez besoin et de passer facilement au raison pour cela.

Je terminerai par cette citation finale de Samuel Beckett :