Get best of the week

Pourquoi écrivons-nous des programmes de si mauvaise qualité?


:
— , ,  — .
- :
— . .
:
— .
— ?
— . , .
— ?
— , , , , , .
- Ils disent que la fiabilité est garantie par une technologie appelée blockchain.
- Ahhhhhhhh !!! Quoi qu'ils disent, ne le touchez pas! Creusez plus profondément. N'oubliez pas les gants!
Source: XKCD , licence Creative Commons 2.5. Un

problème de l'application de comptage mobile de la semaine dernière a ravagé le Congrès du Parti démocrate de l'Iowa. Quelques heures après l'ouverture des réunions à travers l'État, il est devenu clair que quelque chose s'était mal passé. Les résultats sont encore inconnus. Il y avait des messages décrivant des problèmes techniques et des malentendus. Le Parti démocrate de l'Iowa a publié une déclaration qui dément les rumeurs d'une cyberattaque, mais confirme des problèmes techniques avec l'application mobile.

Une semaine plus tard, nous comprenons déjà mieux ce qui s'est passé. Une application mobile a été écrite spécialement pour cet événement dans l'Iowa. Il a été distribué en version bêta , contournant les grands répertoires d'applications. Les utilisateurs ont souffert, mais ont eu du mal à faire fonctionner le programme. Après l'installation, elle était très susceptible de ne pas répondre aux appels. Dans certains lieux de réunion, il n'y avait pas de connexion Internet, ce qui a rendu la demande en ligne inutile. Les démocrates avaient un plan de secours: communiquer les résultats par téléphone, comme d'habitude. Mais les lignes téléphoniques étaient bloquées par des trolls en ligne, ce qui les a bloqués pour le plaisir de Lulz.

Twitter a suivi une vague de hashtags #app et #problems, et les ingénieurs logiciels ont cité KDPV. Je le pensais aussi. Les mots de cette caricature résument bien le sentiment général de ce qui se passe: "Je ne sais pas très bien comment l'exprimer, mais toute notre région est mauvaise dans ce que nous faisons, et si vous comptez sur nous, alors tout le monde va mourir." Les ingénieurs logiciels ne le disent pas directement. Mais cela semble très similaire. Que voulons-nous dire?

Voici ce que nous voulons dire: nous faisons bien les logiciels, à condition que les conséquences d'une panne ne soient pas importantes. En moyenne, les programmes sont assez bons pour fonctionner d'une manière ou d'une autre. Cependant, nous ne sommes pas particulièrement surpris des erreurs dans la plupart des programmes. Ce ne sont pas des incidents rares. De nombreuses pratiques courantes en génie logiciel partent de l'hypothèse que les plantages sont la norme, et surtout, les nouvelles fonctionnalités. L'échec est vraiment bon marché. Si le service en ligne de l'une des plus grandes entreprises est complètement déconnecté pendant deux heures, ils l'oublieront dans une semaine. Cette hypothèse est incarnée dans les mantras communs: «Bougez vite et brisez tout» (Bougez vite et brisez les choses), «Déployez et répétez le cycle» (lancer et itérer).

Le marché récompense généreusement ce comportement "irresponsable". Dans de nombreuses sociétés Web, un petit bénéfice par utilisateur est multiplié par des millions (ou des milliards!) D'utilisateurs. Cela est avantageux pour les entreprises disposant d'applications ou de sites Web grand public. L'implémentation est chère, mais le coût est fini, et la distribution est presque gratuite. L'industrie des logiciels grand public a trouvé un compromis: nous réduisons le taux d'implémentation juste assez pour maintenir notre niveau de défauts modérément bas, mais pas trop.

Nous appelons ce développement logiciel le «modèle économique du site Web»: lorsque les avantages de la mise en œuvre sont élevés et que le coût des nouvelles tentatives est faible, la direction encourage la libération rapide des fonctions. Cela se reflète dans les pratiques modernes de gestion de projet et leur mise en œuvre, dont je parlerai ci-dessous.

Mais, comme je l'ai dit, "nous faisons bien les logiciels, à condition que les conséquences d'une panne ne soient pas importantes". Cette approche conduit à de terribles échecs si les conséquences ne sont pas bon marché, comme dans l'Iowa. La pratique courante du développement de logiciels s'est développée à partir du modèle économique d'Internet, et lorsque les hypothèses de ce modèle sont violées, les ingénieurs logiciels font un mauvais travail.

Comment fonctionne la programmation dans les entreprises Web?


Imaginez la société hypothétique QwertyCo. Il s'agit d'une société de logiciels axée sur le consommateur qui gagne 100 millions de dollars par an. Nous pouvons estimer la taille de QwertyCo en comparant avec d'autres sociétés. WP Engine, l'hébergement WordPress, a atteint 100 millions de dollars ARR en 2018 . Blue Apron a généré 667 millions de dollars pour l'année . Ainsi, QwertyCo est une entreprise de taille moyenne. Elle compte de plusieurs dizaines à plusieurs centaines d'ingénieurs et elle n'a pas émis d'actions en circulation publique.

Tout d'abord, considérons les aspects économiques de la gestion de projet chez QwertyCo. Les dirigeants ont appris que vous ne souhaitez pas annoncer instantanément une nouvelle fonctionnalité. Vous avez un compromis entre la qualité du logiciel, le délai et la vitesse de mise en œuvre.

Quelle est l'importance de la qualité des logiciels pour eux? Pas vraiment. Si le site Web QwertyCo ne fonctionne pas pendant 24 heures par an, ils estiment la perte à seulement 273 972 $ (en supposant que la disponibilité est corrélée linéairement avec les revenus). Ils disent que le site est souvent déconnecté pendant 15 minutes et que personne ne s'en soucie vraiment. Si la fonction plante le site, ils le restaureront et réessaieront plus tard. Les tentatives répétées sont bon marché.

Quelle est la valeur de la nouvelle fonctionnalité pour QwertyCo? Sur la base de mes observations personnelles, un mois de travail d'un ingénieur est capable de faire passer le revenu d'un site optimisé dans une fourchette de -2% à 1%. Il s'agit d'une chance mensuelle d'obtenir 1 million de dollars de revenus QwertyCo supplémentaires pour chaque ingénieur. Des méthodes telles que les tests A / B atténuent même les erreurs: en quelques semaines, vous pouvez détecter les changements négatifs ou neutres et supprimer ces fonctionnalités. Les mauvaises caractéristiques sont bon marché - elles sont actives pendant une durée limitée. Le gain est obtenu pour toujours. Même un faible pourcentage de paris gagnants fait du profit à QwertyCo.

Compte tenu des avantages et des inconvénients, quand QwertyCo devrait-il libérer une fonction? Le calcul économique montre que même les fonctions à haut risque devraient être lancées si elles font parfois des bénéfices. En conséquence, chaque projet se transforme en un jeu d'optimisation: «Combien peut-on mettre en œuvre à cette date? Et si vous en supprimez X? Et si vous supprimez X et Y? Comment accélérer la mise en œuvre d'une certaine partie? »

Considérons maintenant un projet logiciel du point de vue d'un ingénieur logiciel.

Sa principale ressource est le temps. Un développement logiciel sûr prend du temps. Dès qu'un produit franchit un certain seuil de complexité, il a plusieurs étapes de développement (même s'il ne passe pas dans le cadre d'un processus explicite). Ils doivent être planifiés avec l'aide du chef de produit. Le produit est converti en projet ou plan technique, si nécessaire, est divisé en sous-tâches. Ensuite, un code avec des tests est écrit, une révision du code est effectuée, des statistiques sont enregistrées, le produit est intégré avec des panneaux d'information et des alertes. Si nécessaire, un test manuel est effectué. De plus, le codage a souvent un surcoût supplémentaire appelé refactoring.: Modifier un système existant pour faciliter l'implémentation d'une nouvelle fonctionnalité. Dans la mise en œuvre de la "petite" fonction, le codage lui-même ne peut prendre que 10 à 30% du temps.

Comment les développeurs perdent-ils du temps? Le plus souvent, ce sont des défaillances du système. Pendant les temps d'arrêt du site, tout est inclus dans le travail. Les ingénieurs les plus expérimentés arrêtent les projets en cours pour remettre le site sur les rails. Mais le temps mis pour éteindre un incendie est le moment où ils n'apportent pas d'avantages supplémentaires à l'entreprise. Leurs projets sont en retard. Comment réduire les temps d'arrêt? Les tests écrits, la surveillance, les notifications automatisées et les tests manuels réduisent tous les risques d'événements catastrophiques.

Sinon, comment les ingénieurs perdent-ils du temps? Grâce à des bugs plus subtils et rares. Certaines erreurs apparaissent rarement, mais causent de gros dégâts. Peut-être que les utilisateurs perdent des données s'ils effectuent une certaine séquence d'actions. Lorsqu'un ingénieur reçoit un rapport d'une telle erreur, il doit tout quitter et le réparer. Cela détourne l'attention du projet en cours et, progressivement, le temps de ces temps d'arrêt peut augmenter.

En conséquence, les ingénieurs logiciels expérimentés commencent à porter une attention particulière à la qualité du code, ils veulent le vérifier attentivement. C'est pourquoi les organisations d'ingénierie utilisent des méthodes qui à première vue ralentissent la vitesse de développement: analyse de code, intégration continue, observabilité, surveillance, etc. Les erreurs sont moins chères si vous les détectez à un stade précoce, les ingénieurs investissent donc massivement dans la détection précoce des erreurs . Ils se concentrent également sur le refactoring, ce qui simplifie la mise en œuvre. Dans une implémentation plus simple, il y a moins de risques d'erreur.

Ainsi, la gestion et le développement ont des points de vue opposés sur la qualité. Le manuel est d'accord avec un taux d'erreur élevé (mais pas trop élevé), et les ingénieurs veulent que l'erreur soit un minimum absolu.

Comment cela affecte-t-il la gestion de projet? Les gestionnaires et les développeurs divisent le projet en petites tâches. Le délai d'exécution du projet dépend du nombre de tâches et du nombre d'ingénieurs. Le plus souvent, un projet prend trop de temps - et il est ajusté en supprimant des fonctions. Ensuite, les ingénieurs effectuent les tâches. La réalisation de la tâche se fait souvent à l' intérieur du sprint.. Si le temps de sprint est de deux semaines, chaque tâche a un minuteur implicite de deux semaines. Cependant, les affectations prennent souvent plus de temps que vous ne le pensez. Les ingénieurs prennent des décisions de priorisation difficiles pour terminer à temps: "Je peux le faire à la fin du sprint si j'écris des tests de base et si je rate ce refactoring que je prévoyais." Les sprints exercent une pression constante, poussant le développeur. Cela signifie que l'ingénieur peut soit compromettre la qualité, soit admettre un échec lors de la prochaine réunion.

Certains diront que je suis trop sévère sur les sprints, et ils ont raison. En fait, tout cela est dû à la pression du temps. Le processus de sprint n'est qu'un moyen pratique d'augmenter cette pression en l'appliquant plusieurs fois: une fois pendant l'évaluation de l'ensemble du projet et une fois pour chaque tâche. Si le produit est valorisé à la valeur ajoutée pour l'entreprise, il est naturel que le timing de mise en œuvre soit ajusté par lui-même. Les ingénieurs sont également intéressés par une mise en œuvre rapide, mais essaient souvent d'optimiser les coûts à long terme plutôt qu'à court terme. Cependant, de nombreuses organisations ne stimulent souvent la vitesse actuelle qu'à court terme.

Après avoir mis en place de telles incitations, le gestionnaire obtient ce qu'il veut: il peut nommer la fonction et la date future, et la direction et les développeurs discuteront de la façon de le faire. "Je veux que vous fassiez des achats en un clic dans les deux mois sans créer de compte." Les gestionnaires et les développeurs rédigeront toutes les tâches pendant deux semaines et raccourciront la liste jusqu'à ce qu'ils puissent lancer la fonction appelée «achats en un clic». Elle aura un risque d'échec modéré et ne travaillera probablement qu'après quelques itérations. Mais l'échec est temporaire et la fonction est éternelle.

Que se passe-t-il si les hypothèses d'un tel modèle économique sont violées?


Comme je l'ai dit, nous faisons bien les logiciels, à condition que les conséquences d'une panne ne soient pas importantes. Ceci est indiqué par les slogans «Avancez vite et tout casser», «Déployez et répétez». Mais tout le monde peut imaginer une situation où la refonte est coûteuse voire impossible. Dans un pincement, l'effondrement d'un bâtiment peut tuer des milliers de personnes et causer des milliards de dollars de dégâts. Le Congrès des factions de l'Iowa 2020 en est un exemple plus doux. Si l'événement échoue, le soir, tout le monde rentrera chez lui vivant. Mais le parti ne peut pas organiser ces réunions pour la deuxième fois ... sans dépenser beaucoup de temps, d'argent et d'efforts.

Brève note: dans cette section, j'utilise l'expression «à haut risque» comme abréviation pour «situations avec impossibilité de réessayer» et «situations avec une possibilité coûteuse de réessayer».

Que se passe-t-il lorsqu'un modèle de site économique est appliqué dans une situation à haut risque? Prenons un exemple au hasard: disons que vous écrivez une application pour rendre compte des résultats d’une réunion dans l’Iowa. Quelles mesures allez-vous prendre pour écrire, tester et tester l'application?

Tout d'abord, la logistique d'ingénierie: vous devez écrire à la fois une application Android et une application iPhone. Le reporting est une exigence centrale, donc un serveur est nécessaire. Les règles de collecte déroutantes doivent être codées à la fois sur le client et sur le serveur. Le système doit communiquer les résultats à l'utilisateur final; c'est une autre interface qui doit être programmée. Le Parti démocrate a probablement des exigences de validation et de rapport que vous devez écrire dans l'application. De plus, il sera très inapproprié si le serveur tombe en panne pendant la réunion, vous devez donc mettre en place une sorte de système de surveillance.

Ensuite, comment vérifier l'application? Une option consiste à tester les utilisateurs. Vous montrez des images d'une application hypothétique à des utilisateurs potentiels - et posez des questions comme «Que pensez-vous que cet écran fait?» et "Si vous voulez accéder à $ a_thing, où allez-vous cliquer?" La conception nécessite toujours plusieurs itérations, il est donc raisonnable de s'attendre à une qualité élevée après plusieurs cycles de tests. Les grandes entreprises passent souvent plusieurs tours avant d'introduire des fonctionnalités importantes. Parfois, ils annulent même des fonctions après avoir reçu des commentaires avant d'écrire au moins une ligne de code. Les tests utilisateurs sont bon marché. Est-il difficile de trouver cinq personnes qui passeront 15 minutes sur le questionnaire, après avoir reçu une carte-cadeau de cinq dollars en cadeau? Dans notre cas, le plus difficile est de faire un échantillon représentatif,ce qui correspond aux représentants démocratiques de l'Iowa.

Ensuite, vous devez vérifier l'application en action: installez-la et configurez-la sur votre smartphone. Le Parti démocrate doit comprendre comment obtenir des résultats. En cas de panne, vous avez besoin d'un plan de sauvegarde. Un bon test peut inclure une «réunion d'essai», où plusieurs membres du Parti démocratique de l'Iowa téléchargent l'application et communiquent les résultats à un serveur central à une date donnée. Cela permettra d'identifier les problèmes et de décrire la situation globale. La vérification peut être effectuée par étapes à mesure que des parties individuelles du produit sont introduites.

De plus, Internet regorge de méchants. Par exemple, les groupes russes ont largement diffusé la désinformationvia les médias sociaux comme Facebook, Reddit et Twitter. Par conséquent, vous devez vous assurer qu'aucun étranger n'intervient. Comment vérifier l'authenticité des résultats? En plus des méchants, Internet est plein de plaisantins qui sont prêts à perturber n'importe quel événement juste pour le plaisir . Comment notre système résiste-t-il aux attaques DDoS? Sinon, existe-t-il un plan de sauvegarde? Qui est responsable de l'introduction d'un plan de secours en le signalant lors des réunions? Que se passe-t-il si les comptes des membres sont piratés? Si l'entreprise ne dispose pas d'experts en sécurité, il est probable que l'application fasse l'objet d'un audit indépendant.

De plus, comment garantissez-vous qu'aucune erreur dans le logiciel ne faussera les résultats? En conséquence, le Parti démocrate doit se méfier de lui-même: est-il possible d'en croire les résultats s'il y a un traître dans ses rangs? Les résultats devraient être disponibles pour vérification à l'aide de copies papier.

D'accord, arrêtons d'énumérer les problèmes. Une chose est claire: il faut beaucoup de temps et de ressources pour s'assurer que tout fonctionne.

Les créateurs de l'application Iowa Caucus ont reçu 60 000 $ et deux mois. Ils avaient quatre programmeurs. Ce montant n'est pas suffisant pour payer quatre bons programmeurs et d'autres dépenses. L'argent ne peut pas être échangé contre du temps. Il n'y a pratiquement pas d'aide extérieure.

Imaginez que vous utilisez la pratique généralement acceptée de supprimer des tâches d'un projet jusqu'à ce que la chronologie soit réalisable. Vous ferez de votre mieux pour gagner du temps. Un aperçu du catalogue d'applications prend souvent moins d'une journée, mais dans le pire des cas, il peut durer une semaine et l'application peut être rejetée. Alors sautons ceci: les membres démocrates téléchargeront l'application via des liens bêta. Même avec un contrôle de sécurité gratuit, il faudra trop de temps pour répondre à toutes leurs recommandations. Par conséquent, nous refusons le contrôle de sécurité. Peut-être, pendant le développement du backend, vous avez payé au designer 1000 $ pour la création de la mise en page de l'application et du logo. Vous planifiez une série de tests utilisateur (mais sautez-la ensuite lorsque les délais sont dépassés).Déployez rapidement et répétez le cycle! Tout peut toujours être réparé.

Et la programmation prend toujours plus de temps que prévu! Vous rencontrerez des bouchons. Premièrement, les règles de tenue des réunions ne sont pas entièrement claires. Il s'avère toujours qu'une solution numérique s'impose au monde analogique. Le monde réel peut accepter l'ambiguïté et l'incohérence, mais pas le monde numérique. En réponse à vos questions, le Comité du Parti démocrate préparera des clarifications. Cela vous retiendra. Le comité peut également modifier les règles à la dernière seconde. Cela vous amènera à modifier la demande juste avant la date limite. Ensuite, vous avez plusieurs développeurs, ce qui signifie des frais généraux de coordination. Chaque encodeur est-il 100% versé dans le mobile,et dans le développement de serveurs? Maitrisent-ils tous parfaitement React Native? Js? Manuscrit? Communications client-serveur? Quels cadres et bibliothèques avez-vous choisis? Chaque «non» ajoute du temps au développement pour tenir compte de la coordination et de la formation. Tout le monde est-il satisfait des cadres de test que vous utilisez? Je rigole. Quels tests sont là ... Oui, au début, ils ont écrit quelques tests, mais l'application a changé si rapidement qu'ils ont été supprimés.

Le temps n'attend pas. Deux mois ont expiré - vous arrivez à la ligne d'arrivée avec le dernier effort et libérez la version finale.

Sur la base du modèle économique d'un site Internet, terminer à la va-vite est bien. Au final, le rush n'a pas d'importance, car vous avez franchi la ligne d'arrivée! Tous les problèmes peuvent être résolus en quelques semaines, puis passer au projet suivant.

Mais la ruée s'est reflétée à l'Assemblée démocratique de l'Iowa. Au cours de l'événement, des appels ont commencé à arriver avec des plaintes concernant la demande. Des résultats théoriquement impossibles ou des doublons ont commencé à arriver. Bientôt, des programmeurs amusants publieront avec plaisir des photos du KDPV et diront que le Congrès des factions de l'Iowa n'aurait pas du tout dû commander une application, et que le vote ne peut faire confiance qu'à la technologie du papier.

résultats


Cet essai m'a personnellement aidé à conclure: lors de la planification d'un projet, il est nécessaire de formaliser le coût de la modification. Je l'ai fait intuitivement dans le passé, mais cela devrait être concrétisé concrètement. Une telle formalisation permet de comprendre quelles tâches ne peuvent en aucun cas échouer. C’est comme dans ma robotique mobile: il y a de longs cycles de mise en œuvre et les dommages dus au dysfonctionnement pourraient passer par le toit. Nous avons passé beaucoup de temps à développer la surveillance et à créer des méthodes fiables pour supprimer et arrêter les systèmes hors de contrôle. Je travaille également avec les services Web grand public depuis dix ans, où les conséquences d'une défaillance sont moindres. Il y a une plus grande volonté de prendre des dettes à court terme et d'aller de l'avant avec le risque d'échec temporaire, en particulier lorsque le retour en arrière est bon marché et que la perte de données est peu probable. À tout le moins, les stimuli poussent pour un tel comportement.Il existe des techniques spéciales dans notre industrie pour éviter de tels problèmes. L'un d'eux -enquête sur les échecs imaginaires (pré-mortem). Vous devez le faire plus souvent.

L'échec de l'Iowa a un résultat positif. Certains sans rapport avec l'informatique ont réalisé qu'il y avait des erreurs dans les programmes. Dans les années à venir, les sponsors du développement des candidatures aux partis politiques commenceront à se demander: "Qu'est-ce qui garantit que la situation avec le Congrès des fractions de l'Iowa ne se reproduira pas?" Peut-être qu'ils se familiariseront avec la littérature, qui essaie d'enseigner aux gestionnaires comment travailler correctement avec les ingénieurs. Par exemple, le département américain de la Défense a un guide intitulé «Comment reconnaître les faux projets agiles», qui décrit les signes suspects d'un contrat. Les forums pour les startups sont pleins de non-techniciens qui demandent (et obtiennent) des conseils sur l'embauche de développeurs.

L'industrie informatique n'a rien appris. Le Congrès de la faction de l'Iowa a permis d'examiner comment l'hypothèse d'un «coût d'erreur élevé» changera nos processus de base. Mais nous n'avons pas saisi cette occasion et n'en avons rien extrait. L'industrie des logiciels grand public ne fait pas attention aux risques d'erreurs. En fait, nous sommes même satisfaits des erreurs. Si le monde extérieur souhaite améliorer la qualité de notre code dans certains domaines, il doit réglementer ces domaines. Ce ne sera pas la première fois. Loi Sarbanes - Oxley et HIPAA sont des exemples de réglementation dans le développement d'un modèle économique de site Web. La réglementation ne suffit pas, mais elle peut s'avérer nécessaire.

C’est ce que nous voulons dire quand nous disons: "Je ne sais pas trop comment l’exprimer, mais notre région entière est mauvaise dans ce que nous faisons, et si vous comptez sur nous, alors tout le monde mourra." Notre industrie s'est formée dans un environnement où les revers sont bon marché. Et nous souhaitons des progrès rapides. Si la modification est impossible ou trop coûteuse, nos processus habituels fonctionnent mal.

More articles:


All Articles