Bei der Entwicklung dieser App kam kein Hund zu Schaden
(shmck.substack.com)- 2016 wurde eine Woche lang ein Problem verfolgt, bei dem die Funktion zum Hochladen standortbezogener Fotos in einer React-Native-Mobile-App nur in der Android-Beta fehlschlug und sich weder lokal auf Android noch unter iOS reproduzieren ließ
- Die Android-Beta gab trotz fehlgeschlagenem Bild-Upload keine Fehlerrückmeldung aus, und jedes neue Build im Play Store brauchte etwa 1 Stunde, wodurch das Testen von Hypothesen langsam voranging
- Im Vergleich zu Beispielen aus Embedded, Hardware, Chemie und Veterinärmedizin wird deutlich, dass das Debugging in der Softwareentwicklung viel schneller ist und eine deutlich höhere Beobachtbarkeit bietet
- Die tatsächliche Ursache war ein Unterschied von nur einem Zeichen beim Bild-MIME-Typ: Obwohl die Dateiendung
.jpgwar, musste der MIME-Typ"jpeg"statt"jpg"sein - Eine Entwicklungsumgebung, in der sich Logs, Echtzeitbeobachtung, Debugger und wiederholte Experimente günstig einsetzen lassen, ist im Vergleich zu den Feedback-Schleifen anderer Berufe fast schon ein großes Privileg
Foto-Upload, der nur in der Android-Beta fehlschlug
- Die Funktion geolocated photos der React-Native-Mobile-App schien startklar für die Veröffentlichung am Montag, doch nach der Android-Beta-Bereitstellung wurden Bilder nicht hochgeladen
- Lokale Android-Tests und die iOS-Beta funktionierten normal, sodass die Ursache des Fehlers nicht sofort erkennbar war
- Auch nach dem erneuten Hochladen einer Version mit verbesserter Fehlerbehandlung trat der Upload-Fehler weiterhin ohne Rückmeldung auf
- Das Hochladen einer neuen Iteration in den Play Store dauerte etwa 1 Stunde, und währenddessen musste auf die Verteilung des Builds gewartet werden, während schon die nächste Hypothese vorbereitet wurde
Längere Feedback-Schleifen in anderen Berufen
- Ein Embedded-Ingenieur spielt nach der Bereitstellung eines Firmware-Updates auf entfernte Geräte eine Situation durch, in der die Nodes nicht mehr antworten
- Um die Ursache zu finden, müssen die Geräte eingesammelt und analysiert werden
- In manchen Fällen dauert es mehrere Monate, bis klar ist, was schiefgelaufen ist
- Ein Hardware-Ingenieur weist darauf hin, dass neue, remote ausgerollte Hardware Konstruktionsfehler womöglich erst offenlegt, nachdem sie mehrere Jahreszeiten überstanden hat
- Alte Geräte werden per Post zurückgeschickt, damit Korrekturen in die nächste Produktgeneration einfließen können
- In einem Fall wurden zur Verringerung der Hitze Lüftungsöffnungen hinzugefügt, doch die Löcher waren groß genug, dass Hornissen darin Nester bauen konnten – und damit entstand ein noch schlimmerer Bug
- Labortests sind möglich, aber die endgültige Verifikation findet am Ende doch im Feld statt
Wie man mit Fehlschlägen umgeht
- Der CEO erinnert sich an seine Zeit als Chemiker während der Vorbereitung seiner Dissertation: Mit einem großen Forschungsbudget für teure Chemikalien führte er Experimente durch, doch Wochen später sah das Ergebnis nach einem Fehlschlag durch Versuchsfehler aus
- Er konnte nicht herausfinden, was schiefgelaufen war, und konnte auch nicht beantworten, was er anders machen würde, um denselben Fehler nicht zu wiederholen
- Trotzdem erhielt er ein zweites Forschungsbudget, und diese Erfahrung wurde zu einem Beispiel für empathische Führung, die Menschen nach einem Scheitern wieder aufrichtet
Ein Fall aus der Veterinärmedizin mit höherem Risiko
- Ein befreundeter Tierarzt behandelte einen alten, kranken Hund und empfahl den Haltern ein Röntgenbild, doch sie lehnten es aus Kostengründen ab
- Ohne Röntgen war das Beste, was man tun konnte, den Bauch des Hundes von außen abzutasten, wobei ein großer Gegenstand fühlbar war
- Operativ entfernt wurde ein Maiskolbenrest, doch ohne Röntgen ließ sich nicht sicher sagen, ob das wirklich das ganze Problem war
- Am nächsten Tag starb der Hund, und anders als bei Problemen rund um den Launch einer Mobile-App können Fehlschläge in anderen Berufen tatsächlich über Leben und Tod entscheiden
Der Ein-Zeichen-Bug und das Privileg von Debugging-Tools
- Am Freitagmorgen fiel eine Diskrepanz zwischen der Android-Dokumentation und der Codebasis auf, und die Ursache des Problems über die ganze Woche hinweg war ein einziges Zeichen
- Der Bild-MIME-Typ war auf
"jpg"gesetzt, obwohl er tatsächlich"jpeg"hätte sein müssen, während die Datei als.jpggespeichert war - Softwareentwickler können komplexe Abläufe tiefgehend einsehen, Verhalten in Echtzeit überwachen, Logs schreiben und die Ausführung mit einem Debugger anhalten und untersuchen
- Diese Möglichkeiten sind günstig und schnell, und mit nur wenigen Klicks lassen sich Experimente mehrmals täglich wiederholen
- Software kann genauso wichtig und wirkungsvoll sein wie die Arbeit in anderen Berufen, aber Entwickler arbeiten in einer Umgebung, in der man für die vorhandenen Debugging-Tools dankbar sein kann
1 Kommentare
Hacker-News-Kommentare
Eine fast schon parabelhafte Geschichte darüber, wie sich Software Engineering von anderen Berufen unterscheidet — scherzhaft gesagt von „echten“ Berufen.
Ich mag auch die kürzere, pointiertere Version: Ein Softwareingenieur, ein Hardwareingenieur und ein Abteilungsleiter sind auf dem Weg zu einem Meeting in der Schweiz, als auf einer steilen Bergstraße die Bremsen versagen, das Auto gegen die Leitplanke prallt, den Hang hinunterrutscht und wie durch ein Wunder zum Stehen kommt.
Der Abteilungsleiter will ein Meeting einberufen, Vision, Mission und Ziele festlegen und das Kernproblem durch kontinuierliche Verbesserung lösen, und der Hardwareingenieur sagt, man solle mit dem Schweizer Taschenmesser die Bremsen zerlegen und reparieren.
Der Softwareingenieur sagt: „Bevor wir irgendetwas tun, schieben wir das Auto wieder nach oben und sehen nach, ob es sich reproduzieren lässt.“
Gleichzeitig ist der große Nachteil von Software Engineering, dass es mit Abstraktion arbeitet. Sogar das Fundament bewegt sich vollständig.
http://thecodelesscode.com/case/154
Dass wir diese Fähigkeit haben, bedeutet nicht, dass Softwareingenieure lächerlich oder unrealistisch sind.
Engineering im digitalen Raum gibt uns Debugging-Fähigkeiten, die in der physischen Welt an Wunder grenzen. Wenn man 10 identische Objekte herstellen und sie auf 10 verschiedene Arten testen will, ist das buchstäblich nur CTRL+C, CTRL+V. Ich würde gern einen Mechaniker dabei beobachten.
Ich bin das Gejammer wirklich leid, dass Softwareingenieure keine „echten Ingenieure“ seien und man Probleme lösen würde, wenn man nur mehr groß angelegte Vorab-Design-Meetings und noch mehr Planung hätte.
Andere Ingenieurdisziplinen arbeiten nicht so, weil sie viel professioneller wären als wir oder weil diese Methode besser wäre, sondern weil sie gar keine andere Wahl haben. Niemand merkt erst nach dem Bau eines Hotels, dass die Decke 6 Zoll höher sein müsste, reißt dann alles ab und baut es neu.
Wenn man einfach
ceilingHeight += 6ausführen und auf „Rebuild“ klicken könnte, woraufhin sich das Hotel neu aufbaut, automatische Unit-Tests sogar die Barrierefreiheit prüfen und die Gesamtkosten 2,82 Dollar betragen, dann würden sie es natürlich auch so machen.Man sollte diesen Minderwertigkeitskomplex ablegen. Wir betreiben Engineering mit Werkzeugen, von denen Bau- und Maschinenbauingenieure in der realen Welt nur träumen können, und natürlich verändert das den Prozess grundlegend.
Natürlich kommt es vor, dass wir auf ein Problem nicht genügend Prozess anwenden. Aber wenn du glaubst, das sei nur ein Problem der Programmierung, würde ich ein paar Stunden https://www.imdb.com/title/tt4788946/ verschreiben.
Es geht nicht um Überlegenheitsgefühle: Wenn auch nur eines deiner Kriterien fehlt, betreibst du kein Engineering. Meiner Erfahrung nach fehlen bei den meisten Softwareentwicklungen alle vier. Das ist nicht unbedingt schlecht, aber die meiste Softwareentwicklung ist kein Engineering.
Das heißt überhaupt nicht, dass Engineering der Entwicklung überlegen wäre.
Es ist wie der Unterschied zwischen dem Modellieren in Ton und dem Bildhauen in Marmor. Wenn man bei Ton einen Fehler macht, kann man schnell wieder daran herumformen, aber wenn man bei Marmor Material wegnimmt, das nicht hätte entfernt werden dürfen, muss man einen neuen Marmorblock bestellen.
Die Marmor-Bildhauerei in die Welt des Tons zu übertragen, macht einen nur zu einem schlechten oder zumindest sehr ineffizienten Tonbildhauer.
Und es hat auch wenig Sinn, darüber zu streiten, welche Skulptur aus Ton oder Marmor wertvoller ist. Beide haben ihren Platz in der Gesellschaft.
ceilingHeight += 6in der realen Welt am nächsten kommt.Ich habe heute wieder ein Objekt modelliert und gedruckt und gemerkt, dass ein Teil etwa 1 mm dicker sein sollte. 30 Sekunden später ging schon Version 2 an den Drucker.
Das ist wirklich großartig. Ich kann kaum erwarten, dass so etwas so allgegenwärtig wird wie ein Papierdrucker.
https://www.youtube.com/watch?v=NPVT2lvMvOk
Im Lauf meiner Karriere gab es mehrmals Situationen, in denen etwas fehlschlug, aber völlig still — und alle feststeckten. Keine Fehlermeldung, gar nichts.
In vielen dieser Fälle lag es daran, dass eine Low-Level-Third-Party-Library einfach
catch (e) {}gemacht hat. Der erste Fall, den ich früh erlebt habe, war eine gute Lektion, und seitdem lasse ich keinen Fehler mehr stillschweigend durchgehen. Wenigstens ein Log-Eintrag muss sein.Die Software, die du heute schreibst, könnte in fünf Jahren in einer Umgebung eingesetzt werden, die du dir überhaupt nicht vorstellen konntest.
30 Jahre später:
/* X systems I modul body I 14.09.1990 */void xxvcda(int *addr, int sizeof)Er kannte nicht einmal die Sprachfunktion, mit der man aus der vorherigen Exception eine neue auslöst und so den Kontext des Stack-Trace bewahrt. Lustige Sache. Wenigstens ist das nicht mein Hauptjob-Code, aber im Hauptjob gibt es dafür wiederum ganz eigene Arten von Spaß.
DRF hat den Validierungsfehler geschluckt und nur einen allgemeinen Fehler zurückgegeben, sodass es keinen Hinweis gab, und ich musste mich am Ende selbst nach unten durcharbeiten und Logging hinzufügen, um herauszufinden, was eigentlich passierte.
Ein Physikerfreund zitierte oft Rutherfords Ausspruch: „Alle Wissenschaft ist entweder Physik oder Briefmarkensammeln.“
Was er damit meinte, war, dass die Physik im Gegensatz zu Mathematik oder Informatik eine Art der Überprüfung durch die physische Realität hat.
Sein Fachgebiet waren extreme Magnetfelder, und die Experimente liefen so ab: riesige Kupferspulen bauen, so viel Strom hindurchjagen, dass sie schmelzen, dann Sprengstoff um die Spule herum zünden, um für einen winzigen Moment im Zentrum das stärkste Magnetfeld zu erzeugen, das Menschen je geschaffen haben, woraufhin flüssiges Kupfer mit mehreren tausend Grad herumspritzt und der gesamte Aufbau zerstört wird.
In so einer Arbeitsumgebung bedeuten Fehler oder Fehlkalkulationen, dass Menschen sehr schnell und auf schreckliche Weise sterben können. Deshalb stimmte er nicht zu, wenn Mathematik-Doktoranden, deren schlimmster Schaden etwas Kreidestaub auf dem Pullover ist, sich selbst Wissenschaftler nannten.
Anders gesagt: Entweder versucht sie, die Dynamik ihres Gegenstands zu verstehen, oder sie bleibt beim Sammeln interessanter Fakten und beim Benennen des Untersuchungsobjekts stehen.
Für alle, die sich für eine Karriere als Superschurke interessieren, aber nicht wissen, wo sie anfangen sollen: So macht man echte EMPs.
[1] https://en.m.wikipedia.org/wiki/Explosively_pumped_flux_comp...
Nach solchen Vorfällen wünscht man sich immer Korrekturmaßnahmen weiter oben im Stack. Mit geeignetem Logging und Fehlerberichten hätte die Behebung keine Woche gedauert.
Die Bibliothek, die den falschen MIME-Typ
image/jpgbekam, hätte eine Exception werfen, abstürzen oder wenigstens einen deutlich sichtbaren Log-Eintrag erzeugen müssen. Ich frage mich, ob der ursprüngliche Autor einen Bug in diese Bibliothek eingebracht hat.Hatte er Zugriff, um zu bestätigen oder auszuschließen, dass die Bild-Uploads tatsächlich auf dem Server ankamen? Warum funktionierten Uploads in der Testumgebung, aber nicht im Release-Build der App? Was war in der Testumgebung anders?
Theoretisch hätte Shawn genug Zugriff haben sollen, um die Antwort auf „Der Upload klappt, warum ist das Bild dann nicht sichtbar?“ ziemlich schnell zu finden — entweder indem er den Server selbst betreibt oder jemanden um Hilfe bittet, der die Ursache eines still scheiternden Uploads diagnostizieren kann.
Meiner Meinung nach ist die viel wichtigere Lehre nicht „Der Bild-MIME-Typ war
jpgund hättejpegsein müssen“, sondern warum es im Test funktionierte und in Production nicht. Nicht der Bug selbst ist das große Thema, sondern warum die Umgebung den Bug so schwer auffindbar gemacht hat.Bei mir gab es einmal eine Desktop-App mit massivem Fehlverhalten, ohne dass Fehler im Log auftauchten. Erst Tage später stellte sich heraus, dass die File-Handles erschöpft waren und log4net ebenfalls nicht loggen kann, wenn es kein File-Handle mehr bekommt. Die Lösung bestand kurzfristig einfach darin, einen kleinen Bugfix zurückzunehmen, aber der echte Fix war, log4net so anzupassen, dass die Log-Datei immer offen bleibt. Dann werden Fehler auch dann noch protokolliert, wenn die App alle File-Handles verbraucht hat.
Schweigen ist nicht das Ziel. Zu viele Entwickler halten Schweigen für das Ziel, aber das eigentliche Ziel ist Korrektheit. Wenn es keinen Fehler gibt, sollte es ruhig sein, aber bei einem Fehler mit Auswirkungen auf den Nutzer sollte es eine große rote Warnbox geben.
Ich finde, Entwickler sollten lernen, Fehlermeldungen zu mögen. Eine gut geschriebene Fehlermeldung macht die Ursache schnell sichtbar und spart allen viel Zeit.
Wenn dieser Entwickler daraus gelernt hat, künftig öfter Fehlermeldungen anzuzeigen, ist das ein sehr gutes Ergebnis.
Das erinnert mich an einen früheren Kollegen, der oft sagte: „Wir bauen doch keine Flugsicherungssysteme.“ Gemeint war, dass bei Fehlern nicht gleich Menschenleben auf dem Spiel stehen.
Damals haben wir Spiele entwickelt, aber es galt auch für fast jede CRUD-App, die ich je geschrieben habe.
Nebenbei frage ich andere erfahrene technische Führungskräfte, besonders Directors, VPs und CTOs, oft: „Was war der teuerste Fehler, den Sie je gemacht haben?“ Wenn man Junior Engineer ist, sollte man das irgendwann unbedingt einmal tun.
Viele hochrangige Tech-Führungskräfte können Geschichten im Bereich von 100.000 bis 1.000.000 Dollar erzählen. Ich habe sogar jemanden erlebt, der in einem Projekt mehrere Millionen Dollar verbrannt hat und direkt danach befördert wurde. Es ist wichtig zu verstehen, warum so etwas möglich ist und sogar etwas Gutes sein kann.
Der Frust über ein verbuggtes Spiel kann in der realen Welt zu aggressivem Fahrverhalten oder lautstarken Streitigkeiten führen. Es gab Menschen, die sich das Leben nahmen, nachdem ein Computer eine falsche Rechnung verschickt hatte. Es gab Firmen, die zugrunde gingen, weil Software wertvolle Daten verloren hat.
Menschen wurden wegen scheinbar belangloser Social-Media-Apps ermordet, und auf Twitter wurde zur Organisierung von Völkermord angestiftet. Menschen wurden gestalkt und angegriffen, weil Pokemon Go Informationen preisgegeben hat.
Software hat reale Macht. Wäre das nicht so, gäbe es keinen Grund, Software zu schreiben.
Ich habe schon Software entwickelt, die wertvolle Daten verlieren konnte, und arbeite jetzt an Software, die bei Fehlfunktion Überschwemmungen verursachen kann.
Man sollte ein wenig mehr Stolz auf die eigene Arbeit haben.
Als Softwareingenieur habe ich Debugging ziemlich genossen. Denn es zwingt einen dazu, andere Fähigkeiten und Denkweisen einzusetzen als beim Entwerfen und Implementieren
Natürlich heißt das nicht, dass Debugging keinen Stress verursacht. Als wir die Software für die 5ESS-Telefonvermittlungsanlage von AT&T entwickelten, gab es eine Demo, und im Testlabor gab es nur eine einzige Telefonleitung, die für unsere Funktion konfiguriert war
Egal wie oft wir es versuchten, die Software funktionierte nicht, und ich war gestresst, weil ich überzeugt war, dass die Software in Ordnung war, und alles Mögliche überprüfte. Schließlich bat ich den Labortechniker, die Leitung zu kontrollieren, und es stellte sich heraus, dass die einzige konfigurierte Leitung irgendwie abgeklemmt war. Ein dummes Hardwareproblem
Das Debuggen verteilter Systeme in der Cloud ist exponentiell schlimmer, als wenn man alle Services lokal starten kann, und selbst dieses lokal verteilte System ist noch viel schlechter, als ein Problem innerhalb eines einzigen Programms debuggen zu können
Ein echter Debugger macht Debugging ebenfalls sehr viel besser. Ich habe nie verstanden, warum manche Leute auf
printf-Debugging oder auf einen echten Debugger bestehen, als müsse man sich für eines entscheiden. Beides zu nutzen bringt enorme Vorteile. Gutes Tracing ist, wenn möglich, ebenfalls viel besser alsprintf-Debugging und verdient hier ErwähnungAm Anfang des Programmierens habe ich dem Zustand des Nichtwissens unnötig viele Emotionen angehängt, weil ich nicht verstand, warum so etwas passiert. Mit der Zeit habe ich aber die Schleife akzeptiert: „Moment, warum ist das so? Keine Ahnung … ah, warte … wow, es ergibt total Sinn, warum das nicht funktioniert hat!“ Und ich habe verinnerlicht, dass es sich gut anfühlt, wenn man am Ende ankommt
Inzwischen kann der Zustand des Nichtwissens selbst nur noch durch Erwartungen und Verhalten anderer Leute ruiniert werden. Mit der Zeit habe ich gelernt, bei Sprachwahl, Architekturentscheidungen usw. sehr entschlossen zu steuern, damit dieser Prozess leicht und schnell wird
An diesem Punkt meiner Karriere ist es viel einfacher, im Voraus zu erklären, warum AWS Lambda in Bezug auf Performance, Gesamtkosten, Debuggability und Entwicklungsgeschwindigkeit keine gute Wahl ist, als später zu rechtfertigen, warum es so lange dauert, auch nur dieses eine Problem zu beheben
Über den letzten Teil musste ich lachen. Erst gestern habe ich auf der Arbeit ein Problem gelöst, das uns drei Jahre lang gequält hat, und bei uns war der Auslöser der Buchstabe A
Drei Jahre lang hat jemand manuelle Korrekturen vorgenommen, Daten hinein- und hinausgeschoben, und das wurde Teil seiner Arbeit. Für regelmäßige Bereinigungen hatte er sich sogar einen wiederkehrenden Kalendereintrag angelegt. Millionen von Kunden waren darauf angewiesen, dass diese eine Person dafür sorgte, dass auf ihrer Mobilfunkleitung der richtige Datentarif angewendet wurde
Man kann sich vorstellen, welches Chaos entstanden wäre, wenn diese Person es vergessen hätte oder im Urlaub gewesen wäre
Am Ende war die Ursache
if $line->status == STATUS_ACTIVE: an einer Stelle war esActive, an der anderenactive. Kein Hund wurde verletzt, aber über Jahre hinweg verschwand eine nicht bezifferbare Menge GeldDieser arme Mensch ist jetzt nicht mehr unersetzlich. Das ist halb im Scherz gemeint. Bei Software geht es darum, Arbeit effizienter zu machen, aber ich achte auch auf menschliche Anreize
Besonders beim Befüllen von HL7-Feldern auf dem Mac war das sehr schmerzhaft. Das auf der Mac-Tastatur eingegebene Zeichen
’war wohl nicht mit allen HL7-Versionen kompatibel oder passte nicht zu dem Zielsystem, an das HL7 übergeben wurdeIst eine alte Erinnerung, aber wegen des Unterschieds zwischen Wörtern wie
o’clockundo′clockging die Verteilung radiologischer Berichte kaputt. Das lief jahrelang so, bis es entdeckt wurdeHN zeigt
’anders an, als ich es eingegeben habe, aber es ist immer noch dasselbe Zeichen. Dass man den Unterschied beim Debuggen nicht sehen konnte, war die halbe Ursache des Problems, also ist das ziemlich ironischSTATUS_ACTIVEin einem Teil des Codes falsch definiert?Es besteht immer die Gefahr, dass jemand den Tippfehler
refererinHttpHeader::REFERRER„hilfsbereit“ zureferrerkorrigiert. Aber dieser Schreibfehler ist im HTTP-Standard verewigt, und dann geht die Software komplett kaputt. Schuld ist Phillip Hallam-Baker aus der CERN-ZeitDie Anekdote mit dem Wespennest kommt mir sehr bekannt vor
Der Vermieter unseres Bürogebäudes hat draußen am Gebäude eine Touchscreen-Oberfläche installiert, damit man die jeweilige Rezeption anrufen und die Tür öffnen lassen konnte. Das wurde gemacht, weil es kein Empfangspersonal gab, das die Tür sehen konnte
Das Gerät hielt sechs Monate durch und fing dann an, massiv zu spinnen. Der Grund war, dass die Oberfläche, im Grunde ein großes schwarzes Android-Tablet, an der Ostseite des Gebäudes montiert war
Als der Frühling fortschritt, bekam es jeden Tag genug Sonne, um zu überhitzen, und die Touch-Elektronik sowie Teile der Bildschirmhardware gingen kaputt
Bei der Art von Software, die ich entwickle, muss ich mir über Wärmelast keine Gedanken machen
Die Bahngesellschaft schrieb auf Twitter: „Wegen eines Problems bei der Zugabfertigung durch starke Sonneneinstrahlung kam es auf der Strecke durch Lewisham zu starken Störungen“
Außerdem hieß es, die tief stehende Wintersonne habe auf die Abfertigungsmonitore geschienen, sodass die Lokführer sie nicht sehen konnten
Die Nachricht „Ich hab’s endlich gelöst. Es lag am Buchstaben ‚E‘“ ist lustig
Oft sind die einfachsten und kleinsten Bugs gerade die am schwersten zu findenden. Erst heute Morgen habe ich ein oder zwei Stunden damit verloren, einen Off-by-one-Fehler zu suchen
Ursache war ein einzelnes
index + 1, das ich beim Refactoring nicht angepasst hatte