Änderungen in komplexen Softwaresystemen scheinen ewig zu dauern, oder? Selbst Ingenieure denken oft, dass Änderungen über das hinausgehen, was eigentlich sein soll, obwohl wir uns der Komplexität des Systems bewusst sind!

Für die Kunden ist die Situation noch unverständlicher. Das Problem wird durch zufällige Komplexität verschärft, die im Laufe der Zeit aufgrund der schlechten Systemunterstützung hinzukommt. Es besteht das Gefühl, dass wir versuchen, Wasser von einem Schiff mit tausend Löchern zu schöpfen.

Deshalb wird der Kunde früher oder später einen Brief senden: "Warum zum Teufel dauert es so lange?" Vergessen wir nicht, dass wir als Softwareentwickler ein Fenster in die Welt haben, das ihnen oft fehlt. Sie vertrauen uns sehr, aber manchmal braucht eine scheinbar unbedeutende Veränderung wirklich viel Zeit. Aus diesem Grund stellen sich Fragen.

Lassen Sie sich von dieser Frage nicht beleidigen. Nutzen Sie diese Gelegenheit, um Empathie zu zeigen und einer Person ein klareres Bild von der Komplexität des Systems zu geben. Gleichzeitig können Sie Möglichkeiten zur Verbesserung der Situation vorschlagen. Wenn jemand verärgert ist, ist dies der beste Moment, um eine Lösung anzubieten!

Im Folgenden wird ein Brief veröffentlicht, den wir in der einen oder anderen Form im Laufe der Jahre wiederholt verschickt haben. Wir hoffen, es hilft Ihnen bei der Beantwortung dieser Fragen.

Ein Brief

Sehr geehrter Kunde, sehr geehrter Kunde

Ich habe Ihren Kommentar auf der Karte „Vor Ablauf des Auftrags benachrichtigen“ gesehen und werde ihn gerne bei unserem nächsten Treffen besprechen. Als Referenz werde ich hier meine Gedanken zusammenfassen, es ist nicht notwendig zu antworten.

Um Ihre Notiz zu paraphrasieren:

Das Ändern der Frist für die Erledigung von Aufgaben um einen Tag für die Benachrichtigung per E-Mail sollte eine Zeile dauern. Wie kann es 4-8 Stunden dauern? Was fehlt mir?

Einerseits stimme ich Ihnen zu. Ändern Sie einfach den Anforderungsteil von tasks due <= today tasks due <= tomorrow tasks due <= today in tasks due <= tomorrow .

Auf der anderen Seite ignorieren wir versehentlich die inhärente Komplexität und treffen eine Reihe von technischen Entscheidungen, indem wir sie auf eine so vereinfachte Idee reduzieren. Einige davon sollten wir diskutieren.

Teil 1. Warum ist diese kleine Veränderung mehr als es scheint?

Dies ist eine einfache, kleine Änderung, eine Codezeile. Den ganzen Tag damit zu verbringen, sogar einen halben Tag, scheint übertrieben.

Natürlich können Sie eine Änderung in der Produktion nicht einfach einführen, ohne sie zumindest lokal oder auf einem Testserver auszuführen. Sie sollten sicherstellen, dass der Code korrekt ausgeführt wird. Wenn sich die Anforderung ändert, müssen Sie die Ausgabe vergleichen und sicherstellen, dass sie mehr oder weniger korrekt aussieht.

Hier kann der Vergleich der Ausgabe minimal sein, nur eine kleine Stichprobe: Stellen Sie sicher, dass die Ergebnisse sinnvoll sind usw. Dies ist eine Benachrichtigung für interne Mitarbeiter. Wenn die Berechnung nach Datum falsch ist (ein kleiner Fehler), werden wir schnell von den Teams davon erfahren. Wenn es sich beispielsweise um eine E-Mail für Ihre Kunden handeln würde, wäre eine eingehendere Untersuchung erforderlich. Für dieses einfache Testen und Überprüfen reichen jedoch 20 bis 40 Minuten aus, je nachdem, ob etwas Seltsames oder Unerwartetes auftritt. Das Eingraben von Daten kann Zeit kosten. Das Freigeben von Änderungen ohne Überprüfung ist einfach unprofessionelle Fahrlässigkeit.

So fügen wir Zeit für die normale Logistik hinzu, z. B. das Festschreiben eines Codes, das Zusammenführen von Änderungen, das Bereitstellen usw .: Vom Beginn der Arbeit bis zur Freigabe in der Produktion vergeht mindestens eine Stunde von einem kompetenten, professionellen Ingenieur.

Dies setzt natürlich voraus, dass Sie genau wissen, welche Codezeile Sie ändern müssen. Der Task-Workflow befindet sich im Wesentlichen im alten System, aber einige Teile der Logik befinden sich im neuen System. Das Verschieben der Logik vom alten System ist gut, bedeutet jedoch, dass die Funktionalität der Aufgabe derzeit in zwei Systeme unterteilt ist.

Da wir schon so lange zusammenarbeiten, weiß unser Team, welcher Prozess eine E-Mail mit einer abgelaufenen Aufgabe sendet, und kann auf eine Codezeile im neuen System verweisen, die den Prozess initiiert. Wir müssen also keine Zeit damit verschwenden, dies herauszufinden.

Wenn wir uns jedoch den Aufgabencode im alten System ansehen, gibt es mindestens vier verschiedene Möglichkeiten, um festzustellen, ob die Aufgabe fällig ist. Wenn man sich die Muster und das Verhalten von E-Mails ansieht, gibt es mindestens zwei weitere Stellen, an denen anscheinend benutzerdefinierte Logik für diese Aufgabe implementiert ist.

Und dann ist die Benachrichtigungslogik komplizierter als Sie gedacht haben. Es unterscheidet zwischen allgemeinen und individuellen Aufgaben, offen und privat, wiederholend, der Funktion der zusätzlichen Benachrichtigung des Managers im Falle einer überfälligen Aufgabe usw. Wir können jedoch schnell feststellen, dass tatsächlich nur 2 von 6+ Definitionen der überfälligen Aufgabe für Benachrichtigungen verwendet werden. Und nur eines muss geändert werden, um das Ziel zu erreichen.

Eine solche Überprüfung kann leicht eine weitere halbe Stunde oder so dauern, möglicherweise weniger, wenn Sie sich kürzlich in diesem Teil der Codebasis befunden haben. Darüber hinaus bedeutet latente Komplexität, dass wir unsere Schätzung für manuelle Tests übertreffen können. Aber lassen Sie uns einfach 30 Minuten für zusätzlichen Aufwand hinzufügen.

Wir haben also 1,5 Stunden erreicht, um zuversichtlich zu sein, dass die Änderung wie erwartet durchgeführt wird.

Natürlich haben wir noch nicht geprüft, ob andere Prozesse eine veränderbare Abfrage verwenden. Wir möchten andere Funktionen nicht versehentlich stören, indem wir das Konzept der „Frist“ auf den Tag ändern, der vor dem letzten Tag liegt, an dem die Aufgabe erledigt werden soll. Wir sollten die Codebasis unter diesem Gesichtspunkt betrachten. In diesem Fall scheint es keine größeren Abhängigkeiten zu geben - wahrscheinlich, weil sich der Großteil der Benutzeroberfläche noch auf dem alten System befindet. Daher müssen Sie sich keine Gedanken über das Ändern oder Testen anderer Prozesse machen. Im besten Fall sind dies weitere 15-30 Minuten.

Oh, und da sich der Hauptteil der Task-Benutzeroberfläche noch im alten System befindet, müssen wir wirklich einen schnellen Überblick über die Task-Funktionalität in diesem System geben und sicherstellen, dass das Feedback korrekt ist. Wenn die Benutzeroberfläche beispielsweise Aufgaben hervorhebt, deren Frist abgelaufen ist, können wir diese Logik ändern, um sie an die Benachrichtigung anzupassen. Oder kommen Sie zumindest zurück und fragen Sie den Kunden, wie er das machen möchte. Vor kurzem habe ich mir die Funktionalität der Aufgabe im alten System nicht angesehen und ich erinnere mich nicht, ob sie eine Vorstellung von der Frist / Verzögerung hat. Diese Überprüfung fügt weitere 15-30 Minuten hinzu. Vielleicht mehr, wenn das alte System auch mehrere Definitionen einer „Aufgabe“ usw. hat.

Daher gingen wir in den Bereich von 2 bis 2,5 Stunden, um die Aufgabe mit der Gewissheit abzuschließen, dass alles gut gehen wird, ohne unbeabsichtigte Nebenwirkungen oder Verwirrung in der Arbeit des Benutzers.

Teil 2. Wie kann ich diese Zeit verkürzen?

Leider ist das einzige Ergebnis dieser Bemühungen nur die Erfüllung der Aufgabe. Dies ist nicht optimal, was sehr enttäuschend ist. Das vom Entwickler im Laufe der Arbeit erworbene Wissen ist persönlich und kurzlebig. Wenn ein anderer Entwickler (oder wir nach 6 Monaten) erneut Änderungen an diesem Teil des Codes vornehmen muss, muss der Vorgang wiederholt werden.

Es gibt zwei Haupttaktiken, um die Situation zu beheben:

1. Bereinigen Sie die Codebasis aktiv, um Doppelarbeit und Komplexität zu reduzieren.
   
2. Schreiben Sie automatisierte Tests.

Hinweis: Wir haben die Dokumentation bereits besprochen, aber in diesem Fall ist dies nicht die beste Lösung. Die Dokumentation ist nützlich für allgemeine Ideen wie die Erläuterung der Geschäftslogik oder häufig wiederholte Prozesse, z. B. eine Liste neuer Partner. Wenn es jedoch um Code geht, wird die Dokumentation schnell zu umfangreich und veraltet, wenn sich der Code ändert.

Sie haben festgestellt, dass keine dieser Taktiken in unseren 2 bis 2,5 Stunden enthalten ist.

Zum Beispiel bedeutet die Aufrechterhaltung einer sauberen Codebasis, dass wir anstelle der einfachen Ausführung der Aufgabe Fragen stellen:

• Warum gibt es so viele verschiedene Möglichkeiten, Aufgaben zu identifizieren, deren Frist abgelaufen ist / abgelaufen ist?
  
• Brauchen und arbeiten sie alle daran?
  
• Können diese Methoden auf ein oder zwei Konzepte / Methoden reduziert werden?
  
• Kann das Konzept konsolidiert werden, wenn es zwischen dem alten und dem neuen System aufgeteilt ist?

Usw.

Die Antworten auf diese Fragen können sehr schnell sein: Zum Beispiel, wenn wir auf eindeutig toten Code stoßen. Oder sie können mehrere Stunden dauern: Zum Beispiel, wenn Aufgaben in vielen komplexen Prozessen verwendet werden. Sobald wir diese Antworten haben, wird das Refactoring noch länger dauern, um Doppelarbeit / Verwirrung zu reduzieren und eine einzige Beschreibung des „Deadline“ -Konzepts zu erhalten - oder die Konzepte im Code umzubenennen, um klar zu verstehen, wie sie sich unterscheiden und warum.

Aber am Ende wird dieser Teil der Codebasis viel einfacher, es wird einfacher zu lesen und zu ändern sein.

Eine andere Taktik, die wir normalerweise anwenden, ist das automatisierte Testen. In gewissem Sinne ähneln automatisierte Tests einer Dokumentation, die nicht veraltet und leichter zu erkennen ist. Anstatt den Code manuell auszuführen und die Ausgabe anzuzeigen, schreiben wir einen Testcode, der die Anforderung startet und die Ausgabe programmgesteuert überprüft. Jeder Entwickler kann diesen Testcode ausführen, um zu verstehen, wie das System funktionieren soll, und um sicherzustellen, dass es weiterhin so funktioniert.

Wenn Sie ein System mit angemessener Testabdeckung haben, dauern diese Änderungen erheblich weniger Zeit. Sie können die Logik ändern und dann die vollständige Testsuite ausführen und sicherstellen, dass

1. Die Änderung funktioniert ordnungsgemäß.
   
2. Die Änderung hat nichts kaputt gemacht (dies sind noch wertvollere Informationen als im ersten Absatz).

Wenn wir bei Simple Thread Systeme von Grund auf neu erstellen, berücksichtigen wir bei der Bewertung der Fristen immer die Zeit für das Schreiben automatisierter Tests. Dies kann die anfängliche Entwicklung verlangsamen, verbessert jedoch die Arbeits- und Wartungseffizienz erheblich. Erst wenn das System wächst, verstehen Sie wirklich die Bedeutung von Tests, aber an diesem Punkt kann es sehr schwierig sein, Tests an das System zurückzugeben. Das Vorhandensein von Tests vereinfacht auch die Arbeit neuer Mitarbeiter erheblich, und das Ändern des Systemverhaltens ist viel schneller und sicherer.

Teil 3. Woher kommen wir? Wohin gehen wir?

Heutzutage geben wir in Ihrer Einschätzung selten die Zeit an, um Code zu löschen oder Tests zu schreiben. Dies liegt zum Teil daran, dass das Schreiben von Tests von Grund auf einen geringen Aufwand darstellt und das Hinzufügen von Tests zum Backdating der Codebasis eine Menge Arbeit bedeutet, z. B. das Wiederherstellen des Fundaments unter dem Haus, in dem die Menschen leben.

Dies ist teilweise auch darauf zurückzuführen, dass wir sofort mit der Wiederbelebung beginnen und sofort in den Wiederbelebungsmodus wechseln. Wir haben fast täglich Probleme mit der Synchronisierung von Daten von Drittanbietern, wöchentliche Probleme mit der Erstellung von Berichten, ständige Anfragen nach Unterstützung für kleine Datenänderungen, unzureichende Überwachung und Systemprotokollierung usw. Die Codebasis ertrinkt unter dem Gewicht technischer Schulden und wir versuchen fieberhaft, die Systeme am Laufen zu halten schweben, während Löcher mit Klebeband geklebt werden.

Mit der Zeit werden Systeme stabiler und zuverlässiger. Wir automatisieren / bieten eine Benutzeroberfläche für die Selbstbedienung häufiger Supportanfragen. Wir haben immer noch viele technische Schulden, aber wir haben den Notfallmodus verlassen. Ich glaube jedoch nicht, dass wir jemals vollständig von dieser Wiederbelebungsmentalität zu einer proaktiveren, reiferen Planungs- und Ausführungsmentalität übergehen werden.

Wir versuchen, den Code unterwegs zu löschen, und testen ihn immer gründlich. Sorgfältig und fleißig zu sein bedeutet jedoch nicht, die für gute automatisierte Tests erforderliche Infrastruktur proaktiv umzugestalten oder zu schaffen.

Wenn wir nicht anfangen, einige technische Schulden zu bezahlen, werden wir die Situation nie wesentlich verbessern können. Hochqualifizierte, kompetente Entwickler werden Monate brauchen, um zu navigieren und nicht triviale Änderungen vorzunehmen.

Mit anderen Worten, 4-8 Stunden für diese Aufgabe sind ungefähr das 2-4-fache des Angebots, aber es wird den Aufwand für solche Änderungen in Zukunft erheblich reduzieren. Wenn dieser Teil der Codebasis sauberer wäre und eine gute Abdeckung mit automatischen Tests hätte, würde ein kompetenter erfahrener Entwickler ihn in einer Stunde oder weniger fertigstellen. Und der entscheidende Punkt ist, dass der neue Entwickler etwas mehr Zeit in Anspruch nehmen wird.

Für eine solche Änderung der Bedingungen benötigen wir Ihre Zustimmung. Dies ist ein bewusster Versuch, die Leistung Ihres Systems grundlegend zu verbessern, nicht nur die Wahrnehmung durch Benutzer. Ich verstehe, dass es schwierig ist, solchen Investitionen zuzustimmen, gerade weil es keinen sichtbaren Nutzen gibt, aber wir freuen uns, mit Ihnen zusammenzusitzen und einige klare Zahlen zu erstellen, die zeigen, wie sich diese Investitionen aus technischer Sicht langfristig auszahlen werden.

Vielen Dank,
Al