La valeur de la connaissance et de la normalisation des programmeurs

La normalisation favorise la croissance de la tradition des programmeurs, et il n’ya rien de plus précieux pour votre organisation.

Il existe un avantage non quantifiable pour chaque entreprise disposant d’un service informatique: la tradition des programmeurs. L'histoire des programmeurs est ce que les programmeurs apprennent (et partagent) au fil du temps lorsqu'ils travaillent avec un ensemble d'outils. Le savoir des programmeurs est ce que vous avez à peine commencé à acquérir lorsque vous sortez de l’école (à moins que vous n’ayez fait beaucoup de codage en dehors des cours). La connaissance des programmeurs est inestimable.

Dans sa plus simple expression, la connaissance des programmeurs est de «savoir ce que signifie réellement le message d’erreur». Au début de votre carrière, lorsque votre code ou votre build a explosé et que quelqu'un s'est penché par-dessus votre épaule, il a regardé vos messages d'erreur et a dit: «Oh, ouais. D'ACCORD. Alors faites défiler vers le haut, faites défiler vers le haut, faites défiler vers le haut. Le voilà. Vous devez »- cette personne faisait la démonstration de la connaissance des programmeurs.

La connaissance des programmeurs est cependant plus que de la simple connaissance. Lore inclut, par exemple, des solutions conceptuelles flexibles pour des problèmes à la fois micro et macro qui fonctionnent avec les normes de programmation, les outils et la plate-forme de l'organisation. La tradition des programmeurs est une compréhension commune de la façon de penser un problème d'une manière qui tire parti des outils disponibles pour le développeur.

Lore n'a pas non plus de développeur ninja. Le savoir est utile car il est partagé. Le savoir est une ressource d'équipe et, bien que vous puissiez acheter de nouveaux membres, vous ne pouvez pas acheter le savoir de l'équipe.

Je suis très friand de nouvelles technologies, mais les connaissances des programmeurs sont la raison pour laquelle je dis à mes clients qu'ils devraient adopter une plate-forme / un ensemble d'outils et s'y tenir aussi longtemps que possible. Vous ne devez pas abandonner un ensemble d’outils / plate-forme tant qu’il n’y a pas quelque chose que vous voulez vraiment, vraiment faire et qui ne peut pas être fait avec votre ensemble d’outils / plate-forme actuel. À ce stade, vous devez passer au plus jeune ensemble d'outils / plate-forme viable et planifier (au moins au début) de rester sur cette plate-forme jusqu'à votre mort. Peut-être plus longtemps. S'en tenir à une plate-forme permet aux développeurs de développer leur savoir-faire.

Ne vous méprenez pas, partie I: je n'ai aucune utilité pour les gens qui disent que la plate-forme / l'ensemble d'outils qu'ils utilisent est tout ce dont tout le monde aura besoin. Pour citer Vince Gill: «Ils ont arrêté de jouer à Elvis. Ils vont arrêter de vous jouer. " Votre ensemble d'outils de choix devra, à terme, être remplacé. J'ai commencé avec COBOL fonctionnant sur le système d'exploitation VAX / VMS, et j'utilise actuellement Blazor dans .NET 5 dans le navigateur de votre choix (et je peux trouver des personnes pour vous dire que je ne suis pas à la hauteur). Le changement se produit. Acceptez-le.

Ne vous méprenez pas, Partie II: Lorsque vous changez de plate-forme, il y a en fait beaucoup de connaissances que vous emportez avec vous: des outils conceptuels qui fonctionnent partout où vous écrivez du code. En fait, bien que l'apprentissage d'un nouvel ensemble d'outils entraîne des erreurs, il s'avère souvent que le plus gros problème lors du passage à la nouvelle plate-forme est d'avoir trop de connaissances avec vous: vous continuez à appliquer des paradigmes inappropriés à votre nouvel environnement. Le changement se produit. Changer avec lui.

Building Lore

Mais, alors que le changement se produit, rien n'est plus précieux qu'une équipe de développeurs qui connaissent suffisamment bien leurs outils / systèmes / organisation pour savoir où tous les corps sont enterrés. Et cela vient du fait de laisser les développeurs travailler avec un ensemble d'outils aussi longtemps que possible.

C'est, par exemple, la raison pour laquelle nous avons des suites d'outils comme les packages Telerik (insérer le fournisseur de votre choix): Le premier outil ou contrôle le fournisseur construit pour n'importe quelle plate-forme prend du temps et coûte de l'argent. Le second coûte moins cher en raison de la tradition que les développeurs du fournisseur ont développée lors de la création de ce premier outil. Ces fournisseurs ne sont pas stupides: il serait insensé de créer un seul outil pour chaque plate-forme et de ne jamais tirer parti de ce qui a été appris lors de la création du premier outil pour une plate-forme. Ils construisent des suites parce que le savoir est précieux.

Et c'est aussi l'argument pour garder votre boîte à outils petite. Il y a deux problèmes avec l'augmentation de la taille de votre boîte à outils. Tout d'abord, il faut de plus en plus de temps à tout développeur pour créer une réserve de connaissances sur tous les outils. Avec une grande boîte à outils, les développeurs compensent cela en devenant des spécialistes de certains ensembles d'outils au lieu de l'ensemble de la boîte à outils.

Ce qui conduit au deuxième problème: ces spécialistes n'ont personne avec qui partager leur savoir accumulé. Au lieu de devenir une ressource partagée qui est construite et exploitée par tous les membres de l'équipe, la tradition devient un trésor privé, accumulé et utilisé par quelques membres de l'équipe (ou même un seul).

Puisque les gens déménagent, perdre une personne d'un petit groupe coûte plus cher que de perdre un membre d'un grand groupe. C'est pourquoi les équipes agiles préfèrent développer des compétences qui se chevauchent entre les membres (Dan Radigan a quelques sages conseils sur la manipulation des spécialistes ).

Normes de programmation et connaissances

meilleur outil pour ce problème »argumentation et assemblage des« meilleures solutions ». Je suis un grand fan de la normalisation logicielle afin que l’équipe puisse créer des connaissances (jusqu’à ce que, bien sûr, il soit temps de passer à la plate-forme suivante). En outre, si votre plate-forme n’offre qu’une seule solution à un problème et qu’elle n’est pas disponible dans votre boîte à outils, c’est un indicateur qu’il est temps de quitter cette plate-forme.

Et la tradition va dans les deux sens entre les fournisseurs et les développeurs. Je n’ai jamais vu d’étude sur le sujet, mais si vous avez un développeur qui a acheté le Telerik Grid dans le passé (insérez votre fournisseur ici) et qui a maintenant besoin de plus d’outils… Je parie que le développeur commence par examiner d’autres packages Telerik. Je ne pense pas que ces développeurs soient stupides ou paresseux dans la mise en œuvre efficace de la normalisation des composants – ils reconnaissent la valeur du savoir. Une fois que vous savez comment fonctionne l'outil d'un fournisseur, vous avez un aperçu du fonctionnement de tous les outils de ce fournisseur.

Pour le dire autrement: si je suis votre patron et que vous voulez me convaincre que, pour ce projet, vous devez utiliser une nouvelle grille d'un nouveau fournisseur, vous allez avoir une bataille difficile pour me convaincre. Vous auriez beaucoup plus de chance en affirmant que notre fournisseur d'outils actuel ne répond pas à nos besoins (comme le démontre la nécessité de cette nouvelle grille) et que nous devons adopter un nouvel ensemble d'outils.

De même, je suppose, il y a avantages d'obtenir différentes solutions du même fournisseur (un package d'interface utilisateur et un système de contrôle de code source, par exemple) parce que ces solutions «fonctionnent ensemble». Ce n’est pas un argument convaincant pour moi (même si je suis heureux de récolter ces avantages quand ils existent). Je suis développeur: je peux faire fonctionner n'importe quoi avec n'importe quoi d'autre (éventuellement). D'un autre côté, si les deux solutions permettent à l'équipe de tirer parti des connaissances acquises dans une solution lors de l'utilisation de l'autre … eh bien, cela m'intéresse. C'est la tradition des programmeurs et cela vaut beaucoup pour moi.

Soutenir la normalisation

Bien sûr, les fournisseurs d'outils sont très intéressés par la prise en charge de la normalisation (ils appellent leurs suites de produits parce qu'ils veulent que vous achetiez en lots). C'est bon pour les développeurs car bien conçu
Les suites aident à construire la connaissance des programmeurs. Les développeurs Web qui adoptent DevCraft par exemple, obtiennent une suite d'outils JavaScript Telerik .NET et Kendo UI qui non seulement partagent une ressemblance familiale, mais permettent aux magasins de standardiser à la fois au sein des équipes et à l'échelle de l'entreprise (DevCraft inclut Composants d'interface utilisateur, solutions de reporting, bibliothèques de traitement de documents et outils de test / simulation automatisés). L'équipe Progress Telerik continue d'ajouter à cet ensemble d'outils afin que même les nouveaux outils vous permettent d'exploiter votre savoir existant.

Note de l'éditeur: En savoir plus sur l'essai gratuit de 30 jours de DevCraft ou plonger maintenant: [19659003] Essayez Telerik DevCraft