Les lois absurdes du monde du logiciel

Vous êtes-vous déjà demandé pourquoi les gens intelligents comme les développeurs de logiciels se trompent si souvent? Il y a des gens qui l'ont fait. Dans cet article, nous passons en revue certaines des lois non écrites qui décrivent le comportement des professionnels de l'informatique.

Mon premier ordinateur était un Commodore 64. Près de 30 Ko de RAM étaient destinés au système, laissant 32 Ko pour le traitement de texte, les jeux, la comptabilité d'entreprise familiale et à peu près tout ce que je fais avec l'ordinateur de 6 Go que je possède. Cela laisse la question ouverte L'équipement d'aujourd'hui répond-il aux besoins du logiciel ou le logiciel utilise-t-il plus de ressources matérielles parce qu'elles sont disponibles?

En toute honnêteté, les jeux ne sont pas les mêmes, les graphismes ne sont pas de la même qualité et il aurait été impossible de regarder des films et d'écouter de la musique. Cependant, on ne peut s'empêcher de penser que il existe des programmes qui publient des versions et consomment de plus en plus de ressources sans rien apporter de nouveau.

Voici les causes.

Loi de Zawinsky

Le développeur de Netscape, Jamie Zawinsky, a fait valoir que Chaque programme intègre des fonctionnalités jusqu'à ce qu'il soit capable de lire les e-mails. S'il n'y parvient pas, il est remplacé par un autre capable de le faire.

Quand il l'a dit, la blague était qu'il faisait référence à des programmes qui n'étaient pas initialement conçus comme des clients de messagerie. Cela a cessé d'être drôle quand on a découvert que de nombreuses applications sur Google Play demandaient l'autorisation d'accéder aux composants du téléphone et aux données utilisateur dont elles n'avaient pas besoin pour faire leur travail.

Certains ont interprété cela comme faisant partie des tentatives d'espionnage des utilisateurs. Mais c'est probablement la nature humaine de faire quelque chose simplement parce que cela peut être fait.

Le principe de Peter appliqué au logiciel

Lawrence Peter est devenu célèbre pour avoir déclaré que dans une hiérarchie, une personne accède à un poste pour lequel il est manifestement incompétent. Mais il a également eu le temps de dire quelque chose sur les projets complexes:

"Un projet complexe deviendra trop complexe pour être compris même par ses propres développeurs."

Principe du moindre étonnement

Publié dans l'IBM Systems Journal en 1984, ce principe stipule que:

"Si une fonctionnalité requise provoque une grande surprise, la fonctionnalité devra peut-être être repensée."

En d'autres termes, si tout ou partie du logiciel est très différent de ce à quoi l'utilisateur était habitué, le mieux est une refonte. Idéalement, efforcez-vous de réaliser des améliorations incrémentales suffisamment importantes pour être impressionnantes, mais suffisamment petites pour rester familières pour l'utilisateur.

Dommage que Shuttleworth n'en ait pas tenu compte lors du lancement de Unity.

Loi d'entomologie cybernétique

Le premier bogue de l'histoire informatique était réel. Un papillon de nuit est entré dans l'un des relais d'un ordinateur MARK II, provoquant un dysfonctionnement.

Poursuivant la métaphore, la loi de l'entomologie cybernétique soutient que il y aura toujours un autre bogue.

C'est quelque chose que tous les utilisateurs d'ordinateurs savent. Peu importe combien un système d'exploitation est testé, il y a toujours une faille qui est découverte quand il est trop tard.

Loi de Kernighan

Linux Adictos a un plugin installé pour garantir que nous, les auteurs, écrivons de manière conviviale pour les moteurs de recherche. J'ai détesté ça dès le premier jour. Toute tentative d’écrire avec un peu d’envolée littéraire est immédiatement dénoncée par un cercle rouge. Au fil du temps, je me suis habitué et je dois rarement faire des retouches.

La même chose arrive aux programmeurs, qui sont souvent plus intéressés à démontrer leur capacité à coder qu'à écrire un code plus simple, plus facile à comprendre et à maintenir.

Par conséquent, la loi de Kernighan soutient que:

Le débogage est deux fois plus difficile que l'écriture du code en premier lieu. Donc, si vous écrivez le code aussi intelligemment que possible, vous n'êtes pas, par définition, assez intelligent pour le déboguer.

La règle 90/90

Quiconque a lancé un projet à but lucratif dans la vraie vie sait que chaque projet prendra deux fois plus de temps et coûtera deux fois plus cher que prévu, pour réaliser la moitié du bénéfice attendu.

Le monde informatique a ses variantes de cette loi. Par exemple, un Tom Cargill a déclaré:

«Les 90 premiers pour cent du code représentent les 90 premiers pour cent du temps de développement. Les 10% restants du code représentent les 90% restants du temps de développement.

N'était-ce pas clair? Peut-être que la loi de Hofstadter aidera:

"Cela prend toujours plus de temps que prévu, même avec la loi de Hofstadter à l'esprit."

Je suppose que les développeurs Ubuntu et Fedora doivent savoir. Ou du moins, souvenez-vous-en tous les 6 mois.

Loi de Brook

Les projets de logiciels open source ont souvent deux problèmes; financement et manque de collaborateurs. À moins que la seconde ne pose problème. Selon Brook:

"Ajouter de la main-d'œuvre à un projet logiciel qui prend du retard le retardera davantage."

Naturellement, vous ne devez pas simplement mettre à jour les nouveaux encodeurs. Il faudra documenter davantage, il faudra plus de bureaucratie pour garder tout le monde synchronisé, et il y aura probablement des combats.

Et bien sûr, nous ne pouvons pas oublier l'ami Parkinson et son affirmation selon laquelle Peu importe la quantité d'espace vide avec laquelle vous commencez. Vous aurez toujours besoin de plus. Il faisait référence à l'espace de bureau, mais il en va de même pour la RAM et l'espace disque.