Wie können Entwicklerteams eine langsame Leistung in Consumer-Apps verhindern?

Als ich zuvor gefragt habe, was für langsame Software verantwortlich ist, deuteten einige Antworten darauf hin, dass es sich um ein Sozial- und Verwaltungsproblem handelt:

Dies ist kein technisches Problem, sondern ein Marketing- und Managementproblem. Letztendlich sind die Produktmanager dafür verantwortlich, die Spezifikationen für das zu schreiben, was der Benutzer erhalten soll. Viele Dinge können schief gehen: Der Produktmanager hat die Spezifikation nicht mit einer Tastenkombination versehen ... Die QA-Mitarbeiter testen nur mittelmäßig anhand der Spezifikation ... wenn das Produktmanagement und die QA-Mitarbeiter alle am Steuer schlafen. Wir Programmierer können das nicht wettmachen. - Bob Murphy

Die Leute arbeiten an großformatigen Apps. Während sie arbeiten, schleichen sich Leistungsprobleme ein, genau wie Fehler. Der Unterschied ist - Bugs sind "schlecht" - sie schreien "finde mich und repariere mich". Leistungsprobleme sitzen einfach da und werden schlimmer. Programmierer denken oft: "Nun, mein Code hätte kein Leistungsproblem. Stattdessen muss das Management mir eine neuere / größere / schnellere Maschine kaufen." Tatsache ist, wenn Entwickler regelmäßig nach Leistungsproblemen suchen ( was eigentlich sehr einfach ist ), können sie diese einfach beseitigen. - Mike Dunlavey

Wenn es sich also um ein soziales Problem handelt, welche sozialen Mechanismen kann eine Organisation einsetzen, um zu vermeiden, dass langsame Software an ihre Kunden ausgeliefert wird?

Bei richtig geschriebenen und vollständigen Anforderungen gibt es keinen Unterschied zwischen Fehlern und schlechter Leistung . Da Sie die Leistung als nicht funktionsfähige Anforderung angeben, wird eine schlechte Leistung wie jeder andere Fehler zu einem Fehler, der von der Qualitätssicherung abgefangen und von den Entwicklern vor der Veröffentlichung behoben wird.

Gibt es ein soziales Problem? Ich glaube nicht. Das Hauptproblem ist, dass die Anforderungen unvollständig sind. Ich habe jahrelang als Freiberufler gearbeitet und nie eine nicht funktionierende Anforderung gesehen, die besagt, dass eine bestimmte Aufgabe durchschnittlich in maximal N Sekunden ausgeführt werden muss . Wenn sich der Manager / Kunde / Stakeholder oder was auch immer nicht um das Leistungsvermögen kümmert, warum würde ich mich als Entwickler darum kümmern, da sich Leute, die sich darum kümmern müssen, überhaupt nicht darum kümmern?

Ein weiterer Faktor, der die schlechte Leistung beeinflusst, ist die Tatsache, dass Entwickler an teuren PCs arbeiten, die eine gute Leistung erbringen . Wenn Sie jahrelang an einem Quad-Core-PC mit 8 GB RAM, einer High-End-SSD, dem neuesten Betriebssystem usw. arbeiten, können Sie sich nur schwer vorstellen, wie Ihre Anwendung unter Windows XP auf einem Dual-Core-PC ausgeführt wird mit 512 Mo RAM und einer alten Festplatte, die zu 90% gefüllt und jahrelang nicht defragmentiert ist. Leider ist in einigen Ländern der letzte Fall der, den wir für die meisten Nutzer einer App sehen. Je größer der Abstand zwischen Entwickler-PCs und Consumer-PCs ist, desto komplizierter ist es für einen Entwickler, sich um die Leistung seiner App zu kümmern.

Das Problem(?):

• Der Kunde (oder Endbenutzer) beschwert sich nicht (genug)
• Daher sieht der Projekt- (/ Produkt-) Manager dies nicht als Anforderung an
• Somit hat der Entwickler nicht die Zeit, dies zu beheben.

Sie müssen am Anfang anfangen, die Kunden erziehen. Aber wenn sie das iPhone anstelle eines schnelleren, weniger glänzenden Telefons kaufen, verbringen die Entwickler ihre Zeit zu Recht mit Aussehen statt mit Leistung. Die Organisation ist nicht das Problem.

Natürlich können einige Dinge trotzdem helfen. Das Warten auf automatisierte Tests ist ärgerlich. Wenn Sie also automatisierte Tests haben, erhalten die Entwickler ein ständiges Feedback zu Leistungsproblemen, und sie werden es mit größerer Wahrscheinlichkeit lösen (als technisches Problem, nicht als Feature).

Aber man kann nicht alles machen. Es geht darum, Features zu optimieren oder hinzuzufügen, und diejenigen, die das Geld ausgeben, entscheiden.

Aber ein paar gute Neuigkeiten: Mir ist aufgefallen, dass SaaS / Cloud / Buzzword-Anwendungen hier sehr hilfreich sind. Wenn Benutzer zwischen einigen ähnlichen Webanwendungen wählen und Live- Tests durchführen , anstatt zunächst künstliche Listen mit 'erforderlichen' Funktionen zu erstellen, werden sie schneller von der Reaktionsfähigkeit beeinflusst, sodass die Leistung mehr Aufmerksamkeit erhält.

Leider ist das größte Problem, dass Sie nicht alles tun können. Sie haben ein Versanddatum und wissen, dass es langsam ist, aber Sie MÜSSEN die Features X, Y, Z auf den Markt bringen.

In deinen Gedanken kannst du langsam nachbessern, aber die App funktioniert zumindest.

Sie sorgen sich also um Funktionalität und Ästhetik (weil die Benutzer sich allzu oft auf Ästhetik konzentrieren). In der nächsten Version werden Sie die Leistung verbessern.

Die PM bietet Ihnen jedoch nur eine Liste der Funktionen und keine Zeit, um die Leistung zu verbessern.

Und der Teufelskreis geht weiter.

Ich stimme anderen zu, dass wir Wege finden sollten, wie Entwickler sich mehr um das Problem kümmern können, wie sie auf langsamerer Hardware testen und Leistungsziele erreichen können. Das ist alles in Ordnung, aber wirklich, wenn es um die Leistungsoptimierung geht -

Die Leute müssen es wissen - und sie wissen es nicht

Sie denken vielleicht, dass sie es tun, sehen sich jedoch alle leistungsbezogenen Fragen und Antworten auf StackOverFlow und in diesem Forum an. Es ist schmerzhaft, wie viele wenig gesunden Menschenverstand über Leistung zeigen.

Es ist nicht nur etwas, worüber man reden muss, die Leute müssen lernen, indem sie es tun . Das einzige Mal, dass sie in diesem Modus sind, ist, wenn sie eine Klasse besuchen oder neue Dinge aus einem Buch oder Blog lernen.

Ich kann mir also nur vorstellen, dieses Problem zu lösen, indem ich die Leute, die Programmieren unterrichten , in die Hand nehme und ihnen beibringe , wie es geht.

Himmel weiß, ich habe in diesen Foren versucht, wie in -

• Die grundlegende supereinfache Methode
• Eine 43-fache Geschwindigkeit - machen Sie das mit Ihrem Profiler
• Die Gründe warum, in widerwärtigem Detail

Jeder kann das. Sie müssen es nur tatsächlich tun .

Leistung zur Anforderung machen.

Das Schreiben von performantem Code ist schwierig. Es erfordert ein solides Verständnis für Konzepte wie Threading, asynchrone Ereignisbehandlung, Caching und asymptotische Komplexität. Gemessen an den Gruppen von Programmierern, mit denen ich zusammengearbeitet habe, verstehen 20-40% einer bestimmten Gruppe diese Konzepte nicht gut genug, um Leistungsaspekte als selbstverständlich in ihre tägliche Arbeit einzubeziehen.

Diese Programmierer sind für das Unternehmen natürlich immer noch nützlich, werden jedoch Aufgaben zugewiesen, die nicht als leistungskritisch gelten, sodass Sie einen Blu-ray-Player haben, der Netflix-Streams einwandfrei wiedergibt, ohne dass Frames gelöscht werden müssen. Dies dauert jedoch 30-60 Sekunden um den Menüpunkt zu öffnen, der Ihre Warteschlange anzeigt.

Solange Sie kein heißes Softwareunternehmen sind, das es sich leisten kann, 20% Ihrer Mitarbeiter zu entlassen und durch erfahrenere (und teurere) Entwickler zu ersetzen, können Sie dies nur beheben, indem Sie Entwicklerschulungen durchführen und Fehlerberichte einreichen. Ich weiß nicht, wie es bei anderen Unternehmen ist, aber wenn wir Entwickler ein Leistungsproblem feststellen, für das wir keine Zeit oder Geschäftspriorität haben, können wir unseren eigenen Fehlerbericht darüber einreichen. Es kann ein paar Veröffentlichungen dauern, bis sie sich an die Spitze des Backlogs arbeiten, aber sie werden in der Regel irgendwann behoben.

Wenn Leistung eine Anforderung ist, testen Sie es.

Andernfalls kann Wally eine Endlosschleife schreiben und "Es dauert eine Weile" vorzeitig verlassen. Er kann behaupten.

Ihr Software-Abnahmetest sollte einen detaillierten Abnahmetest für verschiedene Betriebsleistungsmerkmale enthalten.

Andernfalls wird keine Leistung in das Produkt integriert.

Die Leistung (wie der Ressourcenverbrauch) sollte auf Subsysteme verteilt werden. Dann können die Subsystem-Abnahmetests sie überprüfen.

Dann können Sie früh und oft auf Leistung testen. Sogar Unit-Tests können dies dann überprüfen.

Entwickler haben es nun als Akzeptanzkriterium und können ihren Ansatz entsprechend organisieren.

Wo ich gerade arbeite, ist der Leistungsstresstest 2x größer als jeder uns bekannte Kundendatensatz. Es bricht regelmäßig eine neue Version des Produkts. Gute Prüfung.

Ich erinnere mich, dass ich Mitte der 90er Jahre einige Zeit damit verbracht habe, etwas zu optimieren, und ein Kollege sagte mir: "Das läuft auf Pentiums, wen interessiert das?" .... das war ein Augenöffner. Leider war es nur die Spitze des Eisbergs, ich habe diese Einstellung während meiner Karriere gehört - obwohl sich der "Pentium" -Teil im Laufe der Zeit geändert hat.

Der einzige Weg, um den durchschnittlichen Entwickler dazu zu bringen, sich darum zu kümmern, besteht darin, dass mangelnde Leistung als Fehler des Kunden angesehen wird. Je nach Anwendung und Zielgruppe kann dies entweder eine einfache oder eine schwierige Aufgabe sein (beides habe ich gesehen). Wenn das Publikum sich nicht für die schlechte Leistung interessiert, werden die Entwickler dies niemals tun (schnell, gut, schnell - wählen Sie zwei).

Ein Programmierer sollte jedoch keinen Brief von der Qualitätssicherung benötigen, um zu erkennen, dass eine Verzögerung von 3 Sekunden zwischen Tastendruck und Antwort inakzeptabel ist

Stimmen Sie zu, dass es nicht sollte. Es sollte mehr als das dauern: ein Beweis, dass die erzielte Verzögerung für Endbenutzer relevant ist .

Da Sie keinen Kontext angegeben haben, ist es durchaus möglich, dass die Verzögerung in der Entwicklungs- / Qualitätssicherungsumgebung durch die lokalen Probleme beim langsamen Zugriff auf Festplatte, Speicher und Netzwerk verursacht wird. In diesem Fall verschwenden Ihre QA und Ihr Entwickler nur ihre Anstrengungen, um Dinge zu reparieren, die für die Endbenutzer keine Rolle spielen.

Das Verlassen auf Entwickler beim Testen der Leistung ist ungefähr so ​​produktiv wie das Würfeln, um ein Stück Funktionalität für die Beschleunigung auszuwählen. Oh und es ist ungefähr so ​​zuverlässig - "Entwickler haben im Allgemeinen eine schreckliche Vorstellung davon, wo die Leistungsprobleme in einer Anwendung tatsächlich liegen werden" ( Brian Goetz ).

• Ich war in einem Projekt, in dem das lahme Management einst entschied, dass die klugen Marketing-Leute und die intelligenten Programmierer gut genug sind, um die Leistungsprobleme der Kunden zu lösen. Was für eine großartige Lektion das war. Abgelehnte Freilassung, ein halbes Jahr Bemühungen in den Papierkorb geworfen, und das Unternehmen verlor fast einen strategischen Partner. Am Ende luden sie Profis ein (Experten für Benchmarking, Statistik, UX, Low-Level-Optimierung usw.) und Profis haben dieses Durcheinander behoben.

Sollten alle Programmierer ihre eigene Qualitätssicherung durchführen, um solche Probleme sofort zu erkennen?

Die Tatsache, dass es machbar ist, bedeutet nicht, dass es der richtige Weg ist. Eher im Gegenteil - meiner Erfahrung nach war dies eine der zuverlässigsten Möglichkeiten, die Produktivität von Programmierern zu beeinträchtigen . Fast so gut wie endlose Meetings und noch besser, als Kandidaten zu interviewen.

• Als Ex-Tester dachte ich einmal, es sollte kein Problem sein, Entwicklungs- und QS-Aktivitäten zu kombinieren. Es sah so aus, als würde der Unterschied zwischen routinemäßigen Entwicklertests und systematischer Qualitätssicherung nicht viel ausmachen. Ich dachte, dass die Trennung von Entwickler und Qualitätssicherung in der Softwareindustrie nur Tradition hat. Ich habe auf ziemlich harte Weise gelernt, dass das nicht so ist. Es stellte sich heraus, dass die Trennung eine Frage des Fokus und der Produktivität war und eine ziemlich ernste Frage war.

Wenn es ein Leistungsproblem gibt, geben Sie mir einfach einen Benchmark und legen Sie die Zielleistung fest, und ich werde mein Bestes geben, um diese zu erreichen. Ich bin nicht so gut in Leistungstests, weiß aber ein oder zwei Dinge über Optimierung.

Ich denke, Sie werden feststellen, dass das Problem in 99% der Fälle im Bereich Creep liegt. Mit dem DVR zum Beispiel. Sie würden denken, dass dies einfach ist, aber dann führt TIVO oder ein Mitbewerber eine neue Funktion ein, die gut angenommen wird. Das nächste, was Sie wissen, ist eine neue Funktion auf dem Teller. Möglicherweise ist es mit dem vorhandenen Produkt nicht kompatibel, und es wird nicht wiederholt, was zu lange dauern wird. Das Feature bleibt also stecken und beeinträchtigt die Leistung. Sicher, die Daten sind da, um die Informationen zu erhalten, aber wenn nicht daran gedacht wurde, diese Informationen zu erhalten, besteht eine gute Chance, dass sie nicht einfach zu bekommen sind. Jetzt ist es ein komplexer Prozess, diese Informationen jedes Mal zu erstellen, wenn Sie sich der Programmliste nähern.

Ignoriert die Entwickler, die sich anscheinend nicht darum kümmern ...

Ich denke, dass die Entwickler, die am Code arbeiten, häufig nicht über die Tools verfügen, um die Leistung kontinuierlich zu messen.

Beispiel: Wenn es möglich ist, die Antwortzeit für Ihre App zu messen (z. B. eine webbasierte Anwendung oder eine Datenbankabfrage usw.) - Erhalten Sie derzeit Benachrichtigungen (E-Mail, SMS usw.), die auf die "Top 10" des Schlimmsten hinweisen Antworten ausführen (oder einen bestimmten Schwellenwert überschreiten)?

In vielen, vielen Fällen erhalten Entwickler diese Informationen nicht aus den "realen" Bereitstellungen. Daher ist es sehr einfach, die Informationen zu ignorieren, die Sie nicht sehen.

Wenn Sie jedoch jeden Tag / in einigen Stunden eine E-Mail erhalten, die angibt, dass das Laden des Bildschirms "x" 13 Sekunden dauert und die folgende SQL-Abfrage ausgeführt wird, sollten SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...Sie besser glauben, dass ein Entwickler das Problem vollständig beheben könnte (und dies hoffentlich auch tun würde) es.

So obwohl ich mag glauben , dass alle Programmierer tun ernst nehmen Leistung denke ich , dass der Mangel an Sichtbarkeit auf die Frage (n) ist oft die Schuldige.

Hinweis: Ich denke, dies ist etwas, worauf sowohl die Entwickler Zugriff fordern (oder sogar eine solche Funktion entwickeln), als auch das Management solche Tools bereitstellen / finanzieren sollte.

Können Sie bessere Beispiele nennen, bei denen wir den Programmierern die Schuld zuschieben können? Abgesehen von Eclipse und einem Kommentator, der bereits darauf hingewiesen hat, dass es Plugins sind, die dies tun (meine erste Installation jeder neuen Eclipse-Version läuft blitzschnell, aber wenn ich die anderen Tools hinzufüge, wird sie langsamer), sind Ihre Beispiele möglicherweise nicht Programmierer und Codebezogen, aber umgebungsbezogen.

Die Zeiten, in denen ein Programm isoliert auf einem Computer ausgeführt und festgestellt wurde, ob es schnell oder langsam ist, sind vorbei. Die anderen Beispiele, die Sie angeben, hängen von ihrer Umgebung ab - der aktuellen Netzwerküberlastung, ob die Back-End-Server überlastet sind, schlecht konfigurierte Netzwerkkarten, ein fehlerhaftes Kabel, die Anzahl der anderen Benutzer in Ihrer Nähe oder Hunderte anderer Variablen. z.B. Unser Hosting-Anbieter berechnete zusätzliche Kosten für Server-Gigabit-Verbindungen, aber schließlich stellten wir fest, dass alles über ein uraltes Firewall-Gerät mit 10-MB-Ports ging. Diese Probleme verschieben sich und sind schwer zu finden.

Einverstanden sind sich viele Dinge, die Programmierer tun können (Minimieren der Bandbreite, Tricks der Benutzeroberfläche, die die Reaktionsfähigkeit verbessern und den Fortschritt anzeigen, um den Eindruck zu erwecken, dass er schnell ist). Aber wenn Sie sich in die reale Welt begeben, gibt es alle möglichen Umstände, die Sie nur aus Erfahrung lernen (und Sie beobachten, wie Ihre Annahmen vor Ihnen auseinanderfallen).

Wie viel sind Sie bereit, für bessere Software zu bezahlen? Wie lange wird der Markt auf bessere Software warten? Wie wenig Cruft willst du zur nächsten Veröffentlichung hinzufügen?

Es ist ein Markt, auf dem viele Kompromisse eingegangen werden. Wenn es wirklich Mist ist, wird (oder sollte) der Markt das Produkt scheitern lassen. Vielleicht gibt es genug Kunden, die mit dem Status Quo leben können?

Ich denke, die allgemeinste Antwort auf dieses Problem ist auch die am schwierigsten zu bewältigende: Jeder Programmierer sollte bei allem, was er tut, auf die Leistung achten. Mir ist auch klar, dass das ein bisschen ein Cop ist.

Abhängig von der Größe des Projekts und des entsprechenden Teams kann es meines Erachtens von großem Wert sein, engagierte Performance-Programmierer zu haben.

Als Beispiel habe ich in einem Team gearbeitet, in dem das Projektteam (einschließlich etwa 30 Entwicklern) mindestens 2 Personen hatte, die sich der Leistungsoptimierung widmeten. Diese spezielle App war auch sehr anfällig für Leistungsprobleme, da es eine Vielzahl von Interoperabilitätskomponenten gab, nicht nur über Webdienste, sondern auch in Bezug auf Legacy-Schichten mit verschiedenen Datenzuordnungs- und Adapterkomponenten.

Erfahrung aus erster Hand ist wichtig. Geben Sie den Entwicklern einen schnellen Computer, auf dem Sie kompilieren und auf dem Sie aufbauen können, aber einen sehr langsam überlasteten Computer (wie ein gewisser Prozentsatz der Benutzer möglicherweise tatsächlich hat), auf dem Ihre App (s) ausgeführt werden können. (Dies kann in Cloud- / Server-basierten Entwicklungsumgebungen durch Partitionieren von VMs oder Servern nach Funktion erfolgen.) Geben Sie ihnen ein Handy mit einem halb entladenen Akku, und fordern Sie sie auf, es nur für die ersten Tests von mobilen Apps zu verwenden.

Wenn sich die Entwickler in Bezug auf Leistung und Akkulaufzeit in den Kunden einfühlen, werden sie die Leistung nicht als eine falsche Verwaltungsspezifikation ansehen, die ganz unten auf der Prioritätenliste steht. (Wie in: "Hey, ich dachte, es wäre eine vorzeitige Optimierung" bis zu spät.)

Stoppen Sie den Kauf des Materials und kommentieren Sie die schlechte Leistung bei allen Online-Rezensionen, die Sie finden.

Wenn die Geräte immer noch verkauft werden, ist die Software "gut genug", um nicht mehr Zeit und Geld in sie zu investieren. Wenn schlechte Bewertungen der Leistung den Umsatz erheblich verringern, ist die Software "nicht gut genug" und muss repariert werden.

Die einzigen Kennzahlen, die einen Hersteller von Konsumgütern interessieren, sind Umsatz und Gewinn pro Einheit.

Ich stimme zu, dass Programmierer besser darin unterrichtet werden sollten, die Leistung zu maximieren usw.

Aber ich denke, die Lösung gibt Programmierern keine fast aussterbende Hardware für den täglichen Gebrauch. Wie stressig es sein wird, wenn Ihr visuelles Studio zweimal am Tag abstürzt. Es dauerte x Sekunden, um das Zeug zu erstellen, y Sekunden, um die Lösung zu öffnen, z Sekunden, um die Fenster zu wechseln. Ich denke nicht, dass es für das Unternehmen sehr kosteneffizient war, da die Hardware billig und die Zeit für Programmierer teuer ist.

Da die nächste Hand, die den Code handhabt, das QA (Testing) -Team ist, wäre es nicht besser, sie über die Bedeutung der Leistung zu unterrichten, einen akzeptablen Leistungsstandard usw. als Unternehmensstandard zu haben (nun, in einer perfekten Welt) , der Leistungsstandard sollte in der Spezifikation sein, aber das kommt nicht sehr oft vor)? (dh das regelmäßige Wechseln der Seite / des Tabs im Unternehmen sollte sofort erfolgen, "Update speichern sollte in x Sekunden erfolgen", wenn es sich um eine wichtige App handelt, dann ...). Der Computer, auf dem die QA-Teams ausgeführt werden, sollte der typische Benutzercomputer sein. (Wir wollen sie nicht verärgern, indem wir ihnen einen 386 geben, sondern ihnen zum Beispiel keinen Quad-Core mit 8 GB RAM geben.) Würden sie sich nicht an die Programmierer wenden, wenn sie genug sauer auf die Aufführung wären?

Ich denke, Client / Projektmanager sollten Programmierer / Qa-Team / Entwickler / Vertreter des Firmenteams dazu zwingen, ihre Präsentation auf der niedrigsten typischen Hardware durchzuführen, die sie haben. (der schwächste Computer in der Firma zum Beispiel). Wenn es neu geschrieben wird, müssen sie Daten darüber sammeln, wie schnell es ist, x in der alten Software zu verarbeiten, und sie mit der Geschwindigkeit der neuen Software vergleichen (dies könnte langsamer sein, da neue Software jedoch zusätzliche Geschäftsprozesse erfordern könnte es sollte ein akzeptables Fenster geben).

Ich habe es bereits gesagt, aber ich sage es noch einmal: Ich denke, eine der besten Möglichkeiten, damit umzugehen, besteht darin, Ihre Entwickler einfach an (relativ) modernster Hardware arbeiten zu lassen.

Für einen typischen Programmierer sind die meisten offiziellen Leistungsüberlegungen nebensächlich, wenn man einfach sagt: "Ist es ärgerlich, wenn ich versuche, es auszuführen?" Wenn sie es ärgerlich finden, werden sie es reparieren (zumindest versuchen). Wenn sie mit der Funktionsweise zufrieden sind, erhalten Sie nur einen halbherzigen Versuch, das Problem zu beheben. Dies hilft auch dabei, Probleme frühzeitig zu finden, bevor ihre Behebung viel teurer wird.

Wenn es zu dem Punkt kommt, dass die Qualitätssicherung Regeln durchsetzen muss, an die die Entwickler wirklich nicht glauben, weil sie die Leistung für angemessen halten, stehen die Chancen gut, dass die meisten "Korrekturen", die Sie erhalten, kreative Möglichkeiten zur Umgehung der Regeln bieten. Keine echten Korrekturen, die das Leben des Endbenutzers verbessern.

Gleichzeitig sollte ich hinzufügen, dass ich dies selten als Problem gesehen habe. Wenn überhaupt, habe ich gesehen, dass Entwickler viel zu viel Zeit damit verbracht haben, die Leistung dort zu verbessern, wo es mir eigentlich egal war (eine Sünde, an der ich oft auch schuld bin).