Die absurden Gesetze der Software-Welt

Haben Sie sich jemals gefragt, warum kluge Leute wie Softwareentwickler es so oft vermasseln? Es gibt Leute, die das getan haben. In diesem Beitrag überprüfen wir Einige der ungeschriebenen Gesetze, die das Verhalten von Fachleuten beschreiben des Rechnens.

Mein erster Computer war ein Commodore 64. Fast 30 KB RAM waren für das System vorgesehen, 32 KB für Textverarbeitung, Spiele, Buchhaltung für Familienunternehmen und fast alles, was ich jetzt mit dem 6-GB-Computer mache, den ich besitze. Das lässt die Frage offen Reagiert die heutige Ausrüstung auf die Anforderungen von Software oder verwendet die Software mehr Hardwareressourcen, weil sie verfügbar sind?

Fairerweise sind die Spiele nicht gleich, die Grafiken haben nicht die gleiche Qualität, und es wäre unmöglich gewesen, Filme anzusehen und Musik zu hören. Man kann jedoch nicht anders, als das zu denken Es gibt Programme, die Versionen veröffentlichen und immer mehr Ressourcen verbrauchen, ohne wirklich etwas Neues beizutragen.

Hier sind die Ursachen.

Zawinskys Gesetz

Der Netscape-Entwickler Jamie Zawinsky argumentierte dies Jedes Programm enthält Funktionen, bis es E-Mails lesen kann. Gelingt ihm dies nicht, wird er durch eine andere Person ersetzt, die dazu in der Lage ist.

Als er es sagte, war der Witz, dass er sich auf Programme bezog, die ursprünglich nicht als E-Mail-Clients gedacht waren. Es hörte auf, lustig zu sein, als festgestellt wurde, dass viele Apps bei Google Play um Erlaubnis für den Zugriff auf Telefonkomponenten und Benutzerdaten baten, die sie für ihre Arbeit nicht benötigten.

Einige interpretierten dies als Teil der Versuche, Benutzer auszuspionieren. Aber es liegt wahrscheinlich in der Natur des Menschen, etwas zu tun, nur weil es getan werden kann.

Peters Prinzip galt für Software

Lawrence Peter wurde berühmt dafür, dass er in einer Hierarchie zu einer Position aufsteigt, für die er grob inkompetent ist. Er hatte aber auch Zeit, etwas über komplexe Projekte zu sagen:

"Ein komplexes Projekt wird zu komplex, um selbst von seinen eigenen Entwicklern verstanden zu werden."

Prinzip des geringsten Erstaunens

Dieses Prinzip, das 1984 im IBM Systems Journal veröffentlicht wurde, besagt Folgendes:

"Wenn eine erforderliche Funktion eine große Überraschung verursacht, muss die Funktion möglicherweise neu gestaltet werden."

Mit anderen Worten, Wenn sich ein Teil oder die gesamte Software stark von dem unterscheidet, an den der Benutzer gewöhnt war, ist das Beste ein Redesign. Im Idealfall bemühen, zu erreichen inkrementelle Verbesserungen, die groß genug sind, um beeindruckend zu sein, aber klein genug, um vertraut zu bleiben für den Benutzer.

Schade, dass Shuttleworth dies beim Start von Unity nicht berücksichtigt hat.

Gesetz über kybernetische Entomologie

Der erste Fehler in der Computergeschichte war real. Eine Motte flog in eines der Relais eines MARK II-Computers und verursachte eine Fehlfunktion.

In Fortsetzung der Metapher gilt das Gesetz der kybernetischen Entomologie Es wird immer noch einen Fehler geben.

Das wissen alle Computerbenutzer. Unabhängig davon, wie oft ein Betriebssystem getestet wird, wird immer ein Fehler entdeckt, wenn es zu spät ist.

Kernighans Gesetz

Linux Adictos hat ein Plugin installiert, um sicherzustellen, dass wir Autoren suchmaschinenfreundlich schreiben. Ich habe es vom ersten Tag an gehasst. Jeder Versuch, mit etwas literarischem Schwung zu schreiben, wird sofort mit einem roten Kreis angeprangert. Mit der Zeit habe ich mich daran gewöhnt und muss nur noch selten Nachbesserungen vornehmen.

Das Gleiche passiert mit Programmierern. Oft sind sie mehr daran interessiert, ihre Fähigkeit zum Codieren zu demonstrieren, als einen einfacheren Code zu schreiben, der einfacher zu verstehen und zu warten ist.

Daher lautet Kernighans Gesetz:

Das Debuggen ist doppelt so schwierig wie das Schreiben des Codes. Wenn Sie den Code also so intelligent wie möglich schreiben, sind Sie per Definition nicht intelligent genug, um ihn zu debuggen. '

Die 90/90-Regel

Jeder, der im wirklichen Leben ein gewinnorientiertes Projekt gestartet hat, weiß, dass jedes Projekt doppelt so lange dauern und doppelt so viel kosten wird wie geplant, um die Hälfte des erwarteten Gewinns zu erzielen.

Die Computerwelt hat ihre Varianten dieses Gesetzes. Zum Beispiel sagte ein Tom Cargill:

„Die ersten 90 Prozent des Codes repräsentieren die ersten 90 Prozent der Entwicklungszeit. Die restlichen 10 Prozent des Codes repräsentieren die anderen 90 Prozent der Entwicklungszeit.

War es nicht klar? Vielleicht hilft Hofstadters Gesetz:

"Es dauert immer länger als erwartet, auch wenn Hofstadters Gesetz im Auge behalten wird."

Ich denke, Ubuntu- und Fedora-Entwickler müssen es wissen. Oder zumindest alle 6 Monate daran denken.

Brooks Gesetz

Open Source-Softwareprojekte haben häufig zwei Probleme. Finanzierung und Mangel an Mitarbeitern. Es sei denn, der zweite ist kein Problem. Laut Brook:

"Das Hinzufügen von Arbeitskräften zu einem Softwareprojekt, das hinter dem Zeitplan zurückliegt, wird es weiter verzögern."

Verständlicherweise müssen Sie nicht nur die neuen Encoder aktualisieren. Es muss mehr dokumentiert werden, es wird mehr Bürokratie erfordern, um alle synchron zu halten, und es wird wahrscheinlich Kämpfe geben.

Und natürlich können wir Freund Parkinson und seine Behauptung nicht vergessen Es spielt keine Rolle, mit wie viel Leerraum Sie beginnen. Sie werden immer mehr brauchen. Er bezog sich auf Büroräume, aber das gleiche gilt für RAM und Speicherplatz.