Le problème que vous résolvez est plus important que le code que vous écrivez

Les programmeurs semblent avoir oublié que le véritable objectif du logiciel est de résoudre de vrais problèmes.

Il y a 50 ans, en 1968, une conférence de travail sur le génie logiciel a été organisée, avec le soutien du Comité scientifique de l'OTAN. À cette époque, les gens ont commencé à remarquer que les logiciels devenaient un élément fondamental de la société. Cependant, il est également devenu trop difficile à comprendre. Après cette conférence, la programmation est devenue une industrie. Et il a commencé à s'éloigner du contrôle des hommes d'affaires.

Quel que soit le chemin parcouru par la programmation depuis lors, il y a toujours un problème avec la séparation entre le développement commercial et le développement de logiciels - ou «ENGINEERING», comme l'a d'abord appelé la conférence. Si les développeurs sont trop concentrés sur le développement, ils peuvent manquer l'objectif du logiciel qu'ils écrivent. Ils peuvent ne pas voir les solutions cachées qui ne nécessitent aucun code.

Voici un exemple.

Il y avait une startup qui a créé un appareil qui permettait à une personne d'ouvrir la porte de sa maison via Bluetooth. Un widget a été utilisé comme interface visuelle, qui était visible même lorsque le téléphone était verrouillé. Il avait un seul bouton appelé "Ouvrir la porte".

Lorsque l'utilisateur s'est approché de chez lui, il a pris le téléphone, a trouvé le widget et a ensuite appuyé sur un bouton pour ouvrir la porte.

Quelqu'un l'a regardé et a demandé:

Si nous utilisons Bluetooth et que notre modèle commercial permet à quiconque possède un téléphone d'entrer dans la maison, pourquoi devrions-nous forcer quelqu'un à prendre le téléphone et à appuyer sur le bouton? Laissez la porte ouverte lorsque l'appareil approche de 1 mètre. Ainsi, nous n'avons pas besoin de payer pour le développement et la programmation de l'interface visuelle!

Cette histoire Bluetooth est un excellent exemple d'une focalisation étroite: l'objectif était d'ouvrir la porte avec un minimum d'effort. Cela n'a aucun sens de développer une interface visuelle si les capteurs sont sans fil.

Si vous savez quels objectifs l'entreprise souhaite atteindre et ce qui a de la valeur pour l'utilisateur, vous pouvez combiner ces connaissances avec vos connaissances en technologie. Ce n'est qu'alors que vous aurez suffisamment d'informations pour trouver les meilleures réponses et conclure que le produit n'a pas besoin d'une interface.

Ceci est un excellent exemple de la façon de résoudre un problème technique sans avoir à écrire de code supplémentaire en plus du code de déverrouillage. Cependant, comme avec Tech Debt , rien ne devrait justifier l' écriture de code merdique.

Tous les codes ne valent pas la peine d'être écrits.

Parfois, la correction d'une erreur grave peut ne pas être une priorité. Si vous avez un échange de crypto-monnaie et que le même paiement a été effectué deux fois dans le système, l'intervention humaine peut être la meilleure solution en termes de coûts et d'avantages, si le coût de résolution de ce problème est élevé.

Ce compromis entre sérieux et priorité me rappelle le modèle que mon collègue m'a récemment montré. Il s'agit de la «Priority Matrix», un modèle bidimensionnel qui peut être utilisé pour hiérarchiser les erreurs en fonction du nombre d'utilisateurs qu'elles affectent et de leur gravité.



Le problème de re-dépôt décrit ci-dessus entre dans la catégorie des inconvénients affectant un utilisateur. Par conséquent, priorité 3.

Tous les bogues ne méritent pas d'être corrigés.

C'est une chose très courante lorsque les développeurs essaient d'écrire un script pour tout. Cependant, certaines tâches répétitives ne valent pas la peine d'être automatisées. Vous n'avez pas besoin de passer du temps à programmer des scripts si vous voulez cacher les connaissances nécessaires sur le fonctionnement de l'équipe principale.

Il y a une différence entre l'encapsulation d'une logique complexe et l'abstraction de connaissances utiles. Parfois, l'information doit être claire. Si vous les résumez, ils peuvent avoir l'effet inverse et seront plus difficiles à comprendre.

Il est plus utile d'utiliser certains types de commandes de bas niveau dans la CLI qu'une commande de haut niveau qui résume les connaissances, comme Git .

Il y a quelques années, je travaillais sur un projet utilisant la livraison incrémentielle . Il s'agissait d'un système de vérification d'identité qui exigeait que l'utilisateur fournisse certaines données personnelles pour vérification par un fournisseur tiers.

Il s'agissait d'une fonctionnalité de validation de champ spéciale que l'équipe voulait créer. Cependant, l'historique de l'audit a été priorisé dans la planification de chaque sprint, car la date limite se rapprochait de plus en plus. En fin de compte, l'équipe a découvert qu'il était inutile d'avoir une validation bizarre.

Et voici pourquoi: la vérification était obligatoire!

Il est dans l'intérêt de l'utilisateur de fournir des informations fiables. Si l'utilisateur fournit des données incorrectes, elles ne seront pas vérifiées et ne pourront pas utiliser le système. De plus, la plupart des navigateurs prenaient en charge la validation HTML standard, ce qui était plutôt bien.

Dans le pire des cas, les utilisateurs qui ne pouvaient pas se vérifier pouvaient appeler le support pour tout vérifier manuellement.

Toutes les fonctions ne valent pas la programmation.

Si vous êtes un développeur et que vous comprenez le problème que vous essayez de résoudre, vous pouvez trouver un meilleur code et parfois vous pouvez vous en passer. Vous n'êtes pas un " Code Monkey " qui est payé pour écrire des caractères à l'écran. Vous êtes un professionnel qui est payé pour résoudre des problèmes.

Cependant, si vous essayez de résoudre tous les problèmes en utilisant la technologie, sans aucune réflexion, vous aurez du mal à comprendre ce qui est précieux pour le client et à trouver de bonnes idées.

Votre but et le but du code que vous avez écrit est de créer de la valeur et de faire du monde existant un meilleur endroit, et non de satisfaire votre vision égocentrique de la façon dont le monde devrait être.

Il y a un dicton: "Si vous n'avez qu'un marteau, tout ressemble à un clou."

Il vaut mieux avoir un clou en premier afin que vous puissiez considérer la nécessité d'un marteau.

Autrement dit, si vous avez d'abord besoin d'un clou.

Merci d'avoir lu l'article!

Si j'ai des erreurs dans la traduction, veuillez en parler dans les commentaires!
Consultez également mon site pour un accès rapide aux questions et réponses javascript - Questions et réponses JavaScript

Je serai très reconnaissant et reconnaissant envers vous)

Je suis sur twitter et vk

Merci beaucoup pour votre attention!