Get best of the week

Warum schreiben wir Programme von so schlechter Qualität?


:
— , ,  — .
- :
— . .
:
— .
— ?
— . , .
— ?
— , , , , , .
- Sie sagen, dass die Zuverlässigkeit durch eine Technologie namens Blockchain garantiert wird.
- Ahhhhhhhh !!! Was auch immer sie sagen, fass es nicht an! Grab tiefer. Vergessen Sie nicht die Handschuhe!
Quelle: XKCD , Creative Commons 2.5-Lizenz. Ein Fehler in

der mobilen Zählanwendung der letzten Woche hat den Kongress der Demokratischen Partei von Iowa verwüstet. Einige Stunden nach der Eröffnung der Treffen im ganzen Staat wurde klar, dass etwas schief gelaufen war. Die Ergebnisse sind noch unbekannt. Es gab Meldungen über technische Probleme und Missverständnisse. Die Iowa Democratic Party gab eine Erklärung ab, in der Gerüchte über einen Cyberangriff bestritten, technische Probleme mit der mobilen App jedoch bestätigt werden.

Eine Woche später verstehen wir bereits besser, was passiert ist. Eine mobile App wurde speziell für diese Veranstaltung in Iowa geschrieben. Es wurde als Beta-Version unter Umgehung großer Anwendungsverzeichnisse verteilt. Die Benutzer litten, hatten jedoch Schwierigkeiten, das Programm zum Laufen zu bringen. Nach der Installation reagierte sie sehr wahrscheinlich nicht auf Anrufe. In einigen Veranstaltungsorten gab es keine Internetverbindung, wodurch die Online-Bewerbung unbrauchbar wurde. Die Demokraten hatten einen Backup-Plan: die Ergebnisse wie gewohnt telefonisch zu melden. Aber die Telefonleitungen waren mit Online-Trollen überfüllt, die sie wegen Lulz verstopften.

Twitter folgte einer Welle von Hashtags #app und #problems, und Softwareentwickler zitierten KDPV. Das dachte ich auch. Worte aus dieser Karikatur fassen das allgemeine Gefühl des Geschehens gut zusammen: "Ich weiß nicht genau, wie ich es ausdrücken soll, aber unser gesamtes Gebiet ist schlecht in dem, was wir tun, und wenn Sie sich auf uns verlassen, werden alle sterben." Softwareentwickler sagen es nicht direkt. Aber es klingt sehr ähnlich. Was meinen wir

Wir meinen Folgendes: Wir machen Software gut, vorausgesetzt, die Folgen eines Ausfalls spielen keine Rolle. Im Durchschnitt sind Programme gut genug, um irgendwie zu funktionieren. Wir sind jedoch nicht besonders überrascht über Fehler in den meisten Programmen. Dies sind keine seltenen Vorfälle. Viele gängige Praktiken in der Softwareentwicklung beruhen auf der Annahme, dass Abstürze die Norm und vor allem auf neuen Funktionen sind. Misserfolg ist wirklich billig. Wenn der Onlinedienst eines der größten Unternehmen zwei Stunden lang vollständig getrennt ist, wird er in einer Woche vergessen. Diese Annahme ist in den gängigen Mantras enthalten: „Bewegen Sie sich schnell und brechen Sie alles“ (Bewegen Sie sich schnell und brechen Sie Dinge), „Rollen Sie den Zyklus aus und wiederholen Sie ihn“ (starten und wiederholen).

Der Markt belohnt großzügig für ein solches "unverantwortliches" Verhalten. In vielen Web-Unternehmen wird ein kleiner Gewinn pro Benutzer mit Millionen (oder Milliarden!) Benutzern multipliziert. Dies ist vorteilhaft für Unternehmen mit Consumer-Apps oder Websites. Die Implementierung ist teuer, aber die Kosten sind begrenzt und die Verteilung ist nahezu kostenlos. Die Consumer-Software-Branche hat einen Kompromiss gefunden: Wir reduzieren die Implementierungsrate gerade so weit, dass unsere Fehlerquote moderat niedrig, aber nicht zu hoch bleibt.

Wir nennen eine solche Softwareentwicklung das „Wirtschaftsmodell der Website“: Wenn die Vorteile der Implementierung hoch und die Kosten für Wiederholungsversuche niedrig sind, fördert das Management die schnelle Freigabe von Funktionen. Dies spiegelt sich in modernen Praktiken des Projektmanagements und ihrer Umsetzung wider, auf die ich weiter unten eingehen werde.

Aber wie gesagt: "Wir machen Software gut, vorausgesetzt, die Folgen eines Ausfalls spielen keine Rolle." Dieser Ansatz führt zu schrecklichen Fehlern, wenn die Folgen nicht billig sind, wie in Iowa. Die gängige Praxis der Softwareentwicklung ist aus dem Wirtschaftsmodell des Internets hervorgegangen, und wenn die Annahmen dieses Modells verletzt werden, leisten Softwareentwickler schlechte Arbeit.

Wie funktioniert die Programmierung in Webunternehmen?


Stellen Sie sich das hypothetische Unternehmen QwertyCo vor. Es ist ein verbraucherorientiertes Softwareunternehmen, das jährlich 100 Millionen US-Dollar verdient. Wir können die Größe von QwertyCo durch Vergleich mit anderen Unternehmen schätzen. WP Engine, WordPress-Hosting, erreichte 2018 einen ARR von 100 Millionen US-Dollar . Blue Apron erwirtschaftete 667 Millionen US-Dollar für das Jahr . Somit ist QwertyCo ein mittelständisches Unternehmen. Sie hat mehrere Dutzend bis mehrere Hundert Ingenieure und hat keine Aktien im öffentlichen Verkehr ausgegeben.

Betrachten Sie zunächst die Wirtschaftlichkeit des Projektmanagements bei QwertyCo. Führungskräfte haben erfahren, dass Sie eine neue Funktion nicht sofort ankündigen möchten. Sie haben einen Kompromiss zwischen Softwarequalität, Frist und Implementierungsgeschwindigkeit.

Wie wichtig ist ihnen die Softwarequalität? Nicht wirklich. Wenn die QwertyCo-Website 24 Stunden im Jahr nicht funktioniert, wird der Verlust auf nur 273.972 USD geschätzt (unter der Annahme, dass die Verfügbarkeit linear mit dem Umsatz korreliert). Sie sagen, dass die Seite oft für 15 Minuten offline geht und sich niemand wirklich darum kümmert. Wenn die Funktion die Site zum Absturz bringt, wird sie zurückgesetzt und später erneut versucht. Wiederholte Versuche sind billig.

Wie wertvoll ist die neue Funktion für QwertyCo? Aufgrund meiner persönlichen Beobachtungen kann ein Monat Arbeit eines Ingenieurs das Einkommen eines optimierten Standorts im Bereich von –2% bis 1% verändern. Dies ist eine monatliche Chance, für jeden Ingenieur zusätzliche QwertyCo-Einnahmen in Höhe von 1 Million US-Dollar zu erzielen. Methoden wie A / B-Tests verringern sogar Fehler: Innerhalb weniger Wochen können Sie negative oder neutrale Änderungen erkennen und diese Funktionen entfernen. Schlechte Eigenschaften sind billig - sie sind für eine begrenzte Zeit aktiv. Gewinnen wird für immer erreicht. Selbst ein geringer Prozentsatz der gewonnenen Wetten bringt QwertyCo Gewinn.

Wann sollte QwertyCo angesichts der Vor- und Nachteile eine Funktion veröffentlichen? Die wirtschaftliche Berechnung zeigt, dass auch Funktionen mit hohem Risiko gestartet werden sollten, wenn sie manchmal einen Gewinn erzielen. Dementsprechend wird jedes Projekt zu einem Optimierungsspiel: „Wie viel kann bis zu diesem Datum implementiert werden?“, „Wie viel Zeit wird für die Implementierung des gesamten Projekts benötigt? Was ist, wenn Sie X daraus entfernen? Was ist, wenn Sie X und Y entfernen? Wie kann die Implementierung eines bestimmten Teils beschleunigt werden? “

Betrachten Sie nun ein Softwareprojekt aus der Sicht eines Softwareentwicklers.

Seine wichtigste Ressource ist die Zeit. Sichere Softwareentwicklung ist zeitaufwändig. Sobald ein Produkt eine bestimmte Komplexitätsschwelle überschreitet, hat es mehrere Entwicklungsstufen (auch wenn sie nicht als Teil eines expliziten Prozesses bestanden werden). Sie sollten mit Hilfe des Produktmanagers geplant werden. Das Produkt wird in ein technisches Projekt umgewandelt oder der Plan wird bei Bedarf in Unteraufgaben unterteilt. Anschließend wird ein Code mit Tests geschrieben, eine Codeüberprüfung durchgeführt, Statistiken aufgezeichnet und das Produkt in Informationstafeln und Warnmeldungen integriert. Bei Bedarf werden manuelle Tests durchgeführt. Darüber hinaus hat die Codierung häufig einen zusätzlichen Aufwand, der als Refactoring bezeichnet wird.: Ändern Sie ein vorhandenes System, um die Implementierung einer neuen Funktion zu erleichtern. Bei der Implementierung der "kleinen" Funktion kann die Codierung selbst nur 10 bis 30% der Zeit in Anspruch nehmen.

Wie verlieren Entwickler Zeit? Meist handelt es sich dabei um Systemfehler. Während der Ausfallzeit der Site ist alles in der Arbeit enthalten. Die erfahrensten Ingenieure stoppen laufende Projekte, um den Standort wieder in Gang zu bringen. Die Zeit, die zum Löschen eines Feuers benötigt wird, ist jedoch die Zeit, in der sie dem Unternehmen keine zusätzlichen Vorteile bringen. Ihre Projekte liegen hinter dem Zeitplan zurück. Wie können Ausfallzeiten reduziert werden? Schriftliche Tests, Überwachung, automatisierte Benachrichtigungen und manuelle Tests verringern das Risiko katastrophaler Ereignisse.

Wie sonst verlieren Ingenieure Zeit? Durch subtilere und seltenere Fehler. Einige Fehler treten selten auf, verursachen jedoch großen Schaden. Möglicherweise verlieren Benutzer Daten, wenn sie eine bestimmte Abfolge von Aktionen ausführen. Wenn ein Ingenieur einen Bericht über einen solchen Fehler erhält, muss er alles beenden und beheben. Dies lenkt vom aktuellen Projekt ab, und die Zeit für solche Ausfallzeiten kann sich allmählich verlängern.

Dementsprechend achten erfahrene Softwareentwickler genau auf die Qualität des Codes und möchten ihn sorgfältig prüfen. Aus diesem Grund verwenden Ingenieurbüros Methoden, die die Entwicklungsgeschwindigkeit zu verlangsamen scheinen: Codeanalyse, kontinuierliche Integration, Beobachtbarkeit, Überwachung usw. Fehler sind billiger, wenn Sie sie frühzeitig erkennen. Daher investieren Ingenieure stark in die Früherkennung von Fehlern . Sie konzentrieren sich auch auf das Refactoring, was die Implementierung vereinfacht. In einer einfacheren Implementierung besteht eine geringere Fehlerwahrscheinlichkeit.

Management und Entwicklung haben daher gegensätzliche Sichtweisen auf die Qualität. Das Handbuch stimmt mit einer hohen Fehlerrate überein (aber nicht zu hoch), und die Ingenieure möchten, dass der Fehler ein absolutes Minimum darstellt.

Wie wirkt sich das auf das Projektmanagement aus? Manager und Entwickler unterteilen das Projekt in kleine Aufgaben. Die Projektvorlaufzeit hängt von der Anzahl der Aufgaben und der Anzahl der Ingenieure ab. Meistens nimmt ein Projekt zu viel Zeit in Anspruch - und wird durch Entfernen von Funktionen angepasst. Dann führen die Ingenieure die Aufgaben aus. Die Realisierung der Aufgabe erfolgt häufig im Sprint.. Wenn die Sprintzeit zwei Wochen beträgt, hat jede Aufgabe einen impliziten Zwei-Wochen-Timer. Aufgaben dauern jedoch oft länger als Sie denken. Ingenieure treffen schwierige Priorisierungsentscheidungen, um pünktlich fertig zu werden: „Ich kann dies bis zum Ende des Sprints tun, wenn ich grundlegende Tests schreibe und das geplante Refactoring überspringe.“ Sprints üben konstanten Druck aus und drücken den Entwickler. Dies bedeutet, dass der Ingenieur entweder Kompromisse bei der Qualität eingehen oder beim nächsten Meeting einen Fehler eingestehen kann.

Einige werden sagen, dass ich bei Sprints zu hart bin, und sie haben Recht. In der Tat ist all dies auf den Zeitdruck zurückzuführen. Der Sprintprozess ist nur eine bequeme Möglichkeit, diesen Druck durch mehrmaliges Anwenden zu erhöhen: einmal während der Bewertung des gesamten Projekts und einmal für jede Aufgabe. Wenn das Produkt mit dem Mehrwert für das Unternehmen bewertet wird, ist es selbstverständlich, dass der Zeitpunkt der Implementierung von selbst angepasst wird. Ingenieure sind auch an einer schnellen Implementierung interessiert, versuchen jedoch häufig, die Kosten langfristig und nicht kurzfristig zu optimieren. Viele Organisationen stimulieren jedoch häufig nur kurzfristig die aktuelle Geschwindigkeit.

Nachdem der Manager solche Anreize geschaffen hat, bekommt er, was er will: Er kann die Funktion und das zukünftige Datum benennen, und Management und Entwickler werden darüber diskutieren, wie dies zu tun ist. "Ich möchte, dass Sie innerhalb von zwei Monaten Ein-Klick-Einkäufe tätigen, ohne ein Konto zu erstellen." Manager und Entwickler schreiben alle Aufgaben zwei Wochen lang auf und verkürzen die Liste, bis sie die Funktion "Ein-Klick-Käufe" starten können. Sie hat ein moderates Ausfallrisiko und wird wahrscheinlich erst nach wenigen Iterationen arbeiten. Aber der Fehler ist vorübergehend und die Funktion ist für immer.

Was passiert, wenn die Annahmen eines solchen Wirtschaftsmodells verletzt werden?


Wie gesagt, wir machen Software gut, vorausgesetzt, die Folgen eines Ausfalls spielen keine Rolle. Dies wird durch die Slogans "Bewegen Sie sich schnell und brechen Sie alles", "Ausrollen und Wiederholen" angezeigt. Aber jeder kann sich eine Situation vorstellen, in der Remaking teuer oder sogar unmöglich ist. Zur Not kann der Einsturz eines Gebäudes Tausende von Menschen töten und Schäden in Milliardenhöhe verursachen. Der Fraktionskongress von Iowa 2020 ist ein milderes Beispiel. Wenn die Veranstaltung fehlschlägt, werden am Abend alle lebend nach Hause gehen. Aber die Partei kann diese Treffen nicht zum zweiten Mal organisieren ... ohne viel Zeit, Geld und Mühe aufzuwenden.

Kurzer Hinweis: In diesem Abschnitt verwende ich den Ausdruck „hohes Risiko“ als Abkürzung für „Situationen mit der Unmöglichkeit, es erneut zu versuchen“ und „Situationen mit einer teuren Möglichkeit, es erneut zu versuchen“.

Was passiert, wenn ein wirtschaftliches Standortmodell in einer Hochrisikosituation angewendet wird? Nehmen wir ein zufälliges Beispiel: Angenommen, Sie schreiben einen Antrag, um über die Ergebnisse eines Meetings in Iowa zu berichten. Welche Schritte werden Sie unternehmen, um die Anwendung zu schreiben, zu testen und zu testen?

Erstens, technische Logistik: Sie müssen sowohl eine Android-App als auch eine iPhone-App schreiben. Die Berichterstellung ist eine zentrale Anforderung, daher wird ein Server benötigt. Verwirrende Erfassungsregeln müssen sowohl auf dem Client als auch auf dem Server codiert werden. Das System sollte die Ergebnisse dem Endbenutzer melden. Dies ist eine weitere Schnittstelle, die programmiert werden muss. Die Demokratische Partei hat wahrscheinlich Validierungs- und Berichtspflichten, die Sie an den Antrag schreiben sollten. Darüber hinaus ist es sehr unangemessen, wenn der Server während des Meetings ausfällt, sodass Sie eine Art Überwachungssystem implementieren müssen.

Wie überprüfe ich als nächstes die Anwendung? Eine Option ist das Testen von Benutzern. Sie zeigen potenziellen Benutzern Bilder einer hypothetischen Anwendung - und stellen Fragen wie "Was macht dieser Bildschirm Ihrer Meinung nach?" und "Wenn Sie zu $ ​​a_thing gelangen möchten, wo werden Sie klicken?" Das Design erfordert immer mehrere Iterationen, daher ist es vernünftig, nach mehreren Testrunden eine hohe Qualität zu erwarten. Große Unternehmen verbringen oft mehrere Runden, bevor sie wichtige Funktionen einführen. Manchmal brechen sie sogar Funktionen ab, nachdem sie Feedback erhalten haben, bevor sie mindestens eine Codezeile schreiben. Benutzertests sind billig. Ist es schwierig, fünf Personen zu finden, die 15 Minuten mit dem Fragebogen verbringen, nachdem sie eine Geschenkkarte für fünf Dollar als Geschenk erhalten haben? In unserem Fall ist es am schwierigsten, eine repräsentative Stichprobe zu erstellen.das entspricht den demokratischen Vertretern von Iowa.

Dann müssen Sie die Anwendung in Aktion überprüfen: Installieren und konfigurieren Sie sie auf Ihrem Smartphone. Die Demokratische Partei muss verstehen, wie man Ergebnisse erzielt. Im Fehlerfall benötigen Sie einen Sicherungsplan. Ein guter Test kann ein „Probetreffen“ umfassen, bei dem mehrere Mitglieder der Iowa Democratic Party die Anwendung herunterladen und die Ergebnisse zu einem bestimmten Zeitpunkt an einen zentralen Server melden. Dadurch werden Probleme identifiziert und die Gesamtsituation umrissen. Die Überprüfung kann schrittweise durchgeführt werden, wenn einzelne Teile des Produkts eingeführt werden.

Darüber hinaus ist das Internet voller Bösewichte. Zum Beispiel haben russische Gruppen Fehlinformationen weit verbreitetüber soziale Medien wie Facebook, Reddit und Twitter. Daher müssen Sie sicherstellen, dass kein Fremder eingreift. Wie überprüfe ich die Echtheit der Ergebnisse? Neben Bösewichten gibt es im Internet viele Joker, die bereit sind, jede Veranstaltung nur zum Spaß zu stören . Wie widersteht unser System DDoS-Angriffen? Wenn nicht, gibt es einen Backup-Plan? Wer ist für die Einführung eines Fallback-Plans verantwortlich, indem er dies bei Besprechungen meldet? Was passiert, wenn Mitgliedskonten gehackt werden? Wenn das Unternehmen keine Sicherheitsexperten hat, sollte der Antrag wahrscheinlich einer unabhängigen Prüfung unterzogen werden.

Wie können Sie außerdem sicherstellen, dass die Software keinen Fehler enthält, der die Ergebnisse verfälscht? Dementsprechend sollte die Demokratische Partei sich selbst gegenüber misstrauisch sein: Kann man den Ergebnissen glauben, wenn sich ein Verräter in ihren Reihen befindet? Die Ergebnisse sollten zur Überprüfung anhand von Papierkopien verfügbar sein.

Okay, hören wir auf, Probleme aufzulisten. Eines ist klar: Es braucht viel Zeit und Ressourcen, um sicherzustellen, dass alles funktioniert.

Die Entwickler der Iowa Caucus-App erhielten 60.000 US-Dollar und zwei Monate. Sie hatten vier Programmierer. Dieser Betrag reicht nicht aus, um vier gute Programmierer und andere Ausgaben zu bezahlen. Geld kann nicht gegen Zeit eingetauscht werden. Es gibt praktisch keine Hilfe von außen.

Stellen Sie sich vor, Sie verwenden die allgemein anerkannte Praxis, Aufgaben aus einem Projekt zu entfernen, bis der Zeitplan realisierbar ist. Sie werden Ihr Bestes tun, um Zeit zu sparen. Eine Vorschau des Anwendungskatalogs dauert häufig weniger als einen Tag, kann jedoch im schlimmsten Fall eine Woche dauern und die Anwendung kann abgelehnt werden. Überspringen wir also Folgendes: Demokratische Mitglieder laden die Anwendung über Beta-Links herunter. Selbst bei einer kostenlosen Sicherheitsüberprüfung wird es zu lange dauern, bis alle Empfehlungen erfüllt sind. Daher lehnen wir die Sicherheitsüberprüfung ab. Möglicherweise haben Sie während der Entwicklung des Backends dem Designer 1000 US-Dollar für die Erstellung des Layouts der Anwendung und des Logos gezahlt. Sie planen eine Runde von Benutzertests (überspringen diese jedoch, wenn die Fristen abgelaufen sind).Schnell ausrollen und Zyklus wiederholen! Alles kann immer repariert werden.

Und die Programmierung dauert immer länger als erwartet! Sie werden auf Stecker stoßen. Erstens sind die Regeln für die Abhaltung von Sitzungen nicht ganz klar. Es stellt sich immer heraus, wenn der analogen Welt eine digitale Lösung auferlegt wird. Die reale Welt kann sich mit Mehrdeutigkeit und Inkonsistenz auseinandersetzen, die digitale Welt jedoch nicht. In Beantwortung Ihrer Fragen wird das Komitee der Demokratischen Partei Klarstellungen vorbereiten. Dies wird Sie zurückhalten. Der Ausschuss kann die Regeln auch in letzter Sekunde ändern. Dies führt dazu, dass Sie den Antrag kurz vor Ablauf der Frist ändern. Als nächstes haben Sie mehrere Entwickler, was einen Koordinierungsaufwand bedeutet. Ist jeder Encoder 100% mobil versiert,und in der Serverentwicklung? Beherrschen sie alle React Native perfekt? Js? Typoskript? Client-Server-Kommunikation? Welche Frameworks und Bibliotheken haben Sie gewählt? Jedes „Nein“ verlängert die Entwicklungszeit, um Koordination und Schulung zu berücksichtigen. Sind alle mit den von Ihnen verwendeten Test-Frameworks zufrieden? Ich mache nur Spaß. Welche Tests gibt es ... Ja, zuerst haben sie ein paar Tests geschrieben, aber die Anwendung hat sich so schnell geändert, dass sie gelöscht wurden.

Die Zeit wartet nicht. Zwei Monate sind abgelaufen - Sie erreichen mit der letzten Anstrengung die Ziellinie und veröffentlichen die endgültige Version.

Basierend auf dem Wirtschaftsmodell einer Website ist es gut, in Eile fertig zu werden. Am Ende spielt der Ansturm keine Rolle, denn Sie haben die Ziellinie überquert! Alle Probleme können in wenigen Wochen behoben werden und dann mit dem nächsten Projekt fortgefahren werden.

Aber der Ansturm spiegelte sich in der Demokratischen Versammlung von Iowa wider. Im Laufe der Veranstaltung kamen Anrufe mit Beschwerden über den Antrag an. Theoretisch unmögliche Ergebnisse oder Duplikate kamen auf. Bald veröffentlichen lustige Programmierer gerne Bilder aus dem KDPV und sagen, dass der Fraktionskongress in Iowa überhaupt keine Bewerbung hätte bestellen dürfen und dass die Abstimmung nur mit Papiertechnologie vertrauenswürdig ist.

Ergebnisse


Dieser Aufsatz hat mir persönlich geholfen zu folgern: Bei der Planung eines Projekts müssen die Kosten für die Änderung formalisiert werden. Ich habe dies in der Vergangenheit intuitiv getan, aber es sollte konkret konkretisiert werden. Eine solche Formalisierung hilft zu verstehen, welche Aufgaben auf keinen Fall fehlschlagen können. Es ist wie in meiner mobilen Robotik: Es gibt lange Implementierungszyklen, und der Schaden durch die Fehlfunktion könnte durch das Dach gehen. Wir haben viel Zeit damit verbracht, die Überwachung zu entwickeln und zuverlässige Methoden zur Unterdrückung und Beendigung außer Kontrolle geratener Systeme zu entwickeln. Ich arbeite seit zehn Jahren auch mit Consumer-Webdiensten, bei denen die Folgen eines Ausfalls geringer sind. Es besteht eine höhere Bereitschaft, kurzfristige Schulden aufzunehmen und das Risiko eines vorübergehenden Ausfalls voranzutreiben, insbesondere wenn der Rollback billig und ein Datenverlust unwahrscheinlich ist. Zumindest drängen Reize auf ein solches Verhalten.In unserer Branche gibt es spezielle Techniken, um solche Probleme zu vermeiden. Einer von ihnen -Untersuchung von imaginären Fehlern (Pre-Mortem). Sie müssen dies öfter tun.

Das Scheitern von Iowa hat ein positives Ergebnis. Einige, die nichts mit der IT zu tun hatten, stellten fest, dass die Programme fehlerhaft waren. In den kommenden Jahren werden Sponsoren der Entwicklung von Anträgen für politische Parteien anfangen zu fragen: "Was garantiert, dass sich die Situation mit dem Fraktionskongress in Iowa nicht wiederholt?" Vielleicht lernen sie die Literatur kennen, die den Managern beibringen soll, wie man richtig mit Ingenieuren arbeitet. Das US-Verteidigungsministerium verfügt beispielsweise über einen Leitfaden mit dem Titel „Erkennen agiler gefälschter Projekte“, in dem verdächtige Anzeichen für einen Vertrag beschrieben werden. Die Foren für Startups sind voll von Nicht-Technikern, die Ratschläge zur Einstellung von Entwicklern einholen (und erhalten).

Die IT-Branche hat nichts gelernt. Der Iowa Faction Congress bot die Gelegenheit zu untersuchen, wie die Annahme „hoher Fehlerkosten“ unsere Kernprozesse verändern wird. Aber wir haben diese Gelegenheit nicht genutzt und nichts daraus extrahiert. Die Consumer-Software-Branche achtet nicht auf die Fehlerrisiken. Wir sind sogar mit den Fehlern zufrieden. Wenn die Außenwelt daran interessiert ist, die Qualität unseres Codes in bestimmten Bereichen zu verbessern, sollten sie diese Bereiche regulieren. Dies wird nicht das erste Mal sein. Sarbanes Law - Oxley und HIPAA sind Beispiele für Regulierung bei der Entwicklung eines Wirtschaftsmodells einer Website. Regulierung ist nicht genug, kann sich aber als notwendig herausstellen.

Das meinen wir, wenn wir sagen: "Ich weiß nicht genau, wie ich es ausdrücken soll, aber unser gesamtes Gebiet ist schlecht in dem, was wir tun, und wenn Sie sich auf uns verlassen, werden alle sterben." Unsere Branche wurde in einem Umfeld gegründet, in dem Rückschläge billig sind. Und wir sind an schnellen Fortschritten interessiert. Wenn eine Änderung unmöglich oder zu teuer ist, funktionieren unsere üblichen Prozesse schlecht.

More articles:


All Articles