L'art de la guerre appliqué au développement de logiciels

Si vous travaillez dans l'industrie du logiciel, il est probable que vous ayez entendu parler du paradigme de conception diviser pour mieux régner , qui consiste essentiellement à diviser de manière récursive un problème en deux ou plusieurs sous-problèmes ( diviser ), jusqu'à ce qu'ils deviennent suffisamment simples pour être résolus directement. ( conquérir ).

Ce que vous ne savez peut-être pas, c'est que ce paradigme provient d'une ancienne stratégie politique (le nom est dérivé du dicton latin diviser et impera ) qui suggère qu'il est possible de garder le contrôle sur ses subordonnés ou ses sujets en encourageant la dissidence entre eux.

Cette stratégie a été utilisée par d'innombrables politiciens et chefs militaires à travers l'histoire, tels que Jules César (qui l'a utilisée pendant la guerre des Gaules pour vaincre les Gaulois militairement forts) et Napoléon (l'expert en artillerie français diviserait les troupes ennemies afin qu'aucune partie ne soit plus forte que ses propres troupes, puis perturber leurs communications, entravant les efforts ennemis pour coordonner et exécuter des attaques).

L'art de la guerre : principes anciens appliqués au développement

Cependant, la règle de diviser pour régner n'est pas la seule stratégie politique qui peut être appliquée au développement de logiciels. Bien que la politique et la guerre aient peu à voir avec le développement de logiciels, tout comme les politiciens et les généraux, les développeurs doivent diriger des subordonnés, coordonner les efforts entre les équipes, trouver les meilleures stratégies pour résoudre les problèmes et administrer les ressources.

L'art de la guerre est un ancien traité militaire écrit au cinquième siècle avant JC et attribué à Sun Tzu, un ancien stratège militaire chinois, dont les théories ont eu une profonde influence sur la philosophie orientale et occidentale.

Malgré son âge, le texte est toujours inclus dans le programme de nombreuses écoles militaires d'Asie de l'Est et il est répertorié comme lecture recommandée dans certaines académies militaires d'Occident. Le texte est divisé en 13 chapitres, chacun consacré à un aspect différent de la guerre.

Cependant, en plus de la guerre, les principes et les enseignements de Sun Tzu ont des applications pratiques dans la politique, les affaires, les sports et, croyez-le ou non, le développement de logiciels. En fait, vous appliquez peut-être certains de ces principes dans votre routine quotidienne, sans même connaître leurs origines.

Détaillé ci-dessous, vous trouverez une brève liste des tactiques de base et des conseils expliqués dans l'Art de la guerre. Ils peuvent probablement être appliqués à votre travail dans l'industrie du logiciel ou dans l'un des nombreux autres secteurs.

Le temps est crucial dans toute campagne

Chapitre II, paragraphe 2

Lorsque vous vous engagez dans un combat réel, si la victoire tarde à venir, alors les armes des hommes s'émoussent et leur ardeur s'atténue.

Ce principe peut s'appliquer au développement logiciel, décrivant en règle générale la relation entre la durée des cycles de développement et le moral du développeur.

Si un groupe de développeurs travaille sur les mêmes projets pendant des mois, sans objectifs clairs ni fin en vue, ils peuvent devenir frustrés et leur productivité peut diminuer.

Le développement de logiciels est une entreprise intellectuelle, la motivation est donc le principal moteur de la productivité. Travailler tous les jours sans percevoir que votre travail génère de vrais résultats peut être très démotivant.

Comme indiqué dans certaines méthodologies agiles, la feuille de route de développement doit être divisée en plusieurs objectifs et jalons, que l'équipe pourrait être en mesure d'atteindre dans des délais courts, et ils vont leur donner un sentiment de progrès et de réalisation.

Chapitre II, paragraphe 18

Dans la guerre, alors, que votre grand objet soit la victoire, et non de longues campagnes.

Cette expression peut être interprétée de deux manières :

Tout d'abord, il peut être considéré comme un précurseur de la philosophie UNIX : écrire des programmes qui font une chose et le font bien . Lors du développement d'un logiciel, vous devez toujours garder à l'esprit l'objectif principal du programme, la fonctionnalité clé qu'il fournit ou le plus gros problème qu'il résout, et assurer une mise en œuvre correcte.

Parfois, vous pourriez être inspiré et penser à une fonctionnalité vraiment cool à ajouter, mais n'oubliez pas que les applications qui ont beaucoup de fonctionnalités peu utilisées ont un nom désobligeant : bloatware .

Deuxièmement, l'énoncé peut également être considéré comme un précurseur de l'un des principes de développement logiciel lean : Livrer aussi vite que possible .

Plus tôt vous livrerez un logiciel sans défauts majeurs, plus vite vous obtiendrez les commentaires du client et vous pourrez intégrer les modifications dans la prochaine itération.

Si, d'un autre côté, vous fournissez un logiciel qui ne fonctionne pas, vous manquerez de précieux commentaires, car les clients n'auront pas la possibilité de le tester correctement. Cela rendra la prochaine étape de développement plus difficile, voire impossible dans des situations où votre prochaine itération dépend des commentaires des clients.

Pas de leadership, pas de résultats

Chapitre III, paragraphe 11

Or le général est le rempart de l'État ; si le rempart est complet sur tous les points, l'État sera fort ; si le rempart est défectueux, l'État sera faible.

Cette citation décrit l'importance du rôle du manager dans une équipe de développement : la réussite d'un projet dépend de la force de toutes les personnes impliquées, et le manager est le rempart du projet. La responsabilité commence au sommet.

Même si les développeurs travaillent souvent seuls (chacun assis derrière un ordinateur, avec une communication limitée avec ses collègues), cela ne signifie pas qu'ils n'ont pas besoin d'un bon leadership. Les chefs de projet sont chargés de maintenir l'équipe sur la bonne voie, d'assurer une communication et une résolution des différends efficaces, et les dirigeants, bien sûr, définissent les priorités du projet (entre autres tâches), leur rôle ne doit donc pas être sous-estimé. Leur responsabilité ne devrait pas non plus être engagée en cas de problème. Imaginez ce qui arriverait à un chef militaire dont l'unité manquerait à son devoir sur le champ de bataille ?

Une équipe peut produire un excellent logiciel même si elle a quelques pommes pourries dans des postes de développement, mais il est peu probable que cela se produise si le chef de projet est la pomme pourrie , quel que soit le nombre de développeurs rockstar que compte l'équipe.

Chapitre VI, paragraphe 28

Ne répétez pas la tactique qui vous a valu une victoire, mais laissez vos méthodes être réglées par l'infinie variété des circonstances.

Parfois, lors du démarrage d'un projet, il est tentant d'utiliser le même ensemble de technologies que nous avons utilisé dans des projets précédemment réussis (le même langage de programmation, les mêmes bibliothèques, le même serveur, etc.). Cependant, à moins que les exigences des nouveaux projets ne soient exactement les mêmes que les précédentes, cela pourrait être une mauvaise approche.

En programmation, comme dans la plupart des domaines, la panacée (un remède supposé capable de guérir toutes les maladies) n'existe pas. Il n'y a pas de combinaison unique de technologies que vous pouvez utiliser pour résoudre tous les problèmes ; chaque technologie a ses avantages et ses inconvénients.

Bien sûr, apprendre un nouveau langage de programmation ou utiliser une API inconnue peut coûter cher au départ mais à long terme, la qualité du logiciel sera supérieure et vous deviendrez un meilleur développeur.

Chapitre XIII, paragraphe 27

Par conséquent, seuls le dirigeant éclairé et le général sage utiliseront la plus haute intelligence de l'armée à des fins d'espionnage, et ainsi ils obtiendront de grands résultats. Les espions sont un élément des plus importants dans la guerre, car d'eux dépend la capacité de déplacement d'une armée.

Cette phrase peut être interprétée comme l'importance d'utiliser des outils de surveillance et des bibliothèques de journalisation pendant la phase de maintenance.

Bien que parfois les clients ne le pensent pas, le développement ne se termine pas lorsque vous obtenez une version stable et entièrement testée. Les logiciels évoluent constamment, que ce soit en corrigeant des bogues, en ajoutant de nouvelles fonctionnalités ou en améliorant l'efficacité.

Et il n'y a pas de meilleure source d'information pour savoir quelles modifications apporter que d'avoir des espions surveillant le logiciel dans les environnements de production, vérifiant quelles fonctionnalités sont les plus utilisées, les erreurs les plus courantes et les opérations les plus longues.

Les rapports d'erreurs, les entrées de journalisation et les données d'utilisation sont fondamentaux pour détecter les bogues, identifier les goulots d'étranglement et autres problèmes, car il n'est pas toujours possible de reproduire les mêmes conditions dans des environnements de test contrôlés.

Travail d'équipe et motivation

Chapitre X, paragraphe 24

Celui qui avance sans chercher la gloire, Qui recule sans échapper au blâme, Celui dont l'unique but est de protéger son peuple et de servir son seigneur, L'homme est un joyau du Royaume.

Fondamentalement, c'est l'ancienne version chinoise de "il n'y a pas de je dans l'équipe" . Il est plus important de travailler avec les autres plutôt que de rechercher un gain personnel.

Le développement de logiciels est une activité complexe qui nécessite que les développeurs travaillent efficacement en équipe. Un bon développeur n'est pas celui qui corrige le plus de bogues, implémente le plus de fonctionnalités ou termine les missions avant la date prévue ; un bon développeur est celui qui aide l'équipe à atteindre ses objectifs.

S'attribuer le mérite de tout ce que vous avez fait, ne pas reconnaître vos erreurs ou en blâmer les autres, ou vous appeler un ninja du code pourrait tromper certains managers inexpérimentés et pourrait même vous obtenir une augmentation, mais vous deviendrez un membre contre-productif de votre équipe.

Chapitre VII, paragraphe 21

Réfléchissez et réfléchissez avant de vous lancer.

Cette phrase indique l'importance des réunions de développement d'équipe, telles que celles proposées par les méthodologies agiles.

Lorsque vous travaillez en équipe, il est important de discuter de tout changement majeur avant de le mettre en œuvre. Peu importe si vous êtes le chef d'équipe, ou si vous êtes la personne la plus expérimentée sur le sujet, vous devriez toujours parler avec, ou au moins informer, le reste de l'équipe.

N'oubliez pas que d'autres développeurs pourraient vous donner un aperçu des parties inconnues du logiciel. Cela signifie qu'ils pourraient commencer à mettre en œuvre les changements plus rapidement que prévu, car ils pourraient être pleinement conscients des effets de ces changements.

Chapitre X, paragraphe 25

Considérez vos soldats comme vos enfants, et ils vous suivront dans les vallées les plus profondes ; considérez-les comme vos propres fils bien-aimés, et ils vous soutiendront jusqu'à la mort.

Cette citation indique l'importance de la motivation, un principe de management parfois oublié par les managers et les chefs d'équipe. Les développeurs motivés écriront un meilleur code, travailleront plus vite, commettront moins d'erreurs et seront plus disposés à consacrer des heures supplémentaires.

La motivation doit être générée par les managers, en s'intéressant véritablement à leurs subordonnés, en les écoutant, en se souciant de leur équilibre travail-vie personnelle, en créant des environnements de travail positifs et en se souciant de leurs parcours professionnels.

Aussi, il ne faut pas confondre motivation et rémunération. Des études récentes démontrent que l'argent ne motive pas la plupart des travailleurs, l'argent est surtout bon pour attirer et retenir les employés, mais pas pour les rendre heureux dans leur travail. Les augmentations et les promotions ne doivent donc pas être considérées comme des outils de motivation.

Sortir des sentiers battus

Chapitre V, paragraphes 7, 8 et 9

Il n'y a pas plus de cinq notes de musique, mais les combinaisons de ces cinq donnent lieu à plus de mélodies qu'on ne peut jamais en entendre.

Il n'y a pas plus de cinq couleurs primaires, mais en combinaison, elles produisent plus de teintes qu'on n'en a jamais vu.

Il n'y a pas plus de cinq goûts cardinaux, mais leurs combinaisons donnent plus de saveurs qu'on ne peut jamais en goûter.

L'un des avantages de la programmation est que les possibilités sont infinies. vous pouvez développer pratiquement où vous voulez (du moins, tant que ce n'est pas un problème NP-complet).

Applications mobiles, sites Web, jeux, applications de bureau… si vous connaissez la programmation, tous sont à votre portée.

Chapitre III, paragraphe 1

Dans l'art pratique de la guerre, la meilleure chose à faire est de prendre le pays ennemi entier et intact ; le briser et le détruire n'est pas si bon. De même, il vaut mieux capturer une armée entière que de la détruire, capturer un régiment, un détachement ou une compagnie entière que de les détruire.

Lorsque vous travaillez sur un projet avec une grande base de code, il est courant de trouver des modules ou des sections de code qui ont été implémentés avec de mauvaises pratiques ou en utilisant des bibliothèques obsolètes. Bien qu'il puisse être tentant d'effacer (ou de détruire) ce code, ce n'est peut-être pas la meilleure idée pour plusieurs raisons :

• Le code hérité n'est pas nécessairement mauvais, parfois c'est du bon code qui a été écrit alors que d'autres méthodologies et technologies étaient considérées comme la voie à suivre. Cependant, ce n'est pas parce qu'il est vieux qu'il ne fonctionne pas.

• Vous risquez de perdre du temps à corriger du code qui fonctionne toujours au lieu de vous concentrer sur la correction d'autres parties plus critiques du code.

• À moins que vous ne soyez vraiment sûr de ce que vous faites, remplacer une section de code qui fonctionne signifie que vous risquez d'introduire de nouvelles erreurs ou bogues.

Cela ne signifie pas que l'expression « Si ce n'est pas cassé, ne le répare pas » est une bonne stratégie, mais que chaque projet a des priorités, des objectifs et des contraintes de temps. Donc, si vous trouvez du code qui pourrait être amélioré, discutez-en avec le reste de l'équipe ou avec le chef de projet afin de déterminer quand l'optimiser.

Chapitre VIII, paragraphe 3

Il y a des routes qu'il ne faut pas suivre, des armées qu'il ne faut pas attaquer, des villes qu'il ne faut pas assiéger, des positions qu'il ne faut pas contester, des commandements du souverain auxquels il ne faut pas obéir.

Même s'il ne le dit pas directement, nous pourrions interpréter ce principe comme un avertissement pour éviter les anti-modèles.

Bien que l'utilisation d'un anti-modèle puisse résoudre un problème à court terme, vous devez vous rappeler qu'à long terme, cela sera contre-productif. Ainsi, peu importe le temps que vous gagnez, le nombre de bogues que vous corrigez ou la commodité pour vous, évitez-les.

Pourtant, il y a des moments où vous pourriez être tenté d'utiliser un anti-modèle pour résoudre une tâche urgente, en vous promettant de mettre en œuvre une solution appropriée lorsque vous aurez plus de temps, mais souvenez-vous de l'une des lois de Murphy : toutes les solutions rapides deviennent des changements permanents.

Conclusion

Bien que le développement de logiciels soit différent du commandement de soldats en temps de guerre ou de la direction d'un pays, tout cela doit résoudre des problèmes qui nécessitent un travail d'équipe, un bon leadership, de l'efficacité et des solutions à long terme.

Cependant, l' Art de la guerre n'est pas le seul livre qui contient des principes applicables au développement de logiciels. Le Prince de Niccolo Machiavel en est un exemple.

En fait, voici une liste de citations de Machiavel qui sont toujours d'actualité. Essayez de deviner quels sont les principes correspondants dans le monde du développement logiciel.

1. Le lion ne peut pas se protéger des pièges et le renard ne peut pas se défendre des loups. Il faut donc être renard pour reconnaître les pièges, et lion pour effrayer les loups.
2. N'essayez jamais de gagner par la force ce qui peut être gagné par la tromperie.
3. Jamais rien de grand n'a été réalisé sans danger.
4. Quiconque désire un succès constant doit changer sa conduite avec le temps.
5. Les hommes en général jugent plus sur les apparences que sur la réalité. Tous les hommes ont des yeux, mais peu ont le don de pénétration.
6. Celui qui veut être obéi doit savoir commander.
7. La sagesse consiste à savoir distinguer la nature du mal et à choisir le moindre mal.
8. Il n'y a pas moyen d'éviter la guerre ; elle ne peut être que différée à l'avantage de votre ennemi.
9. La nature crée peu d'hommes courageux ; l'industrie et la formation en font beaucoup.