Kategorien
Zündet die Savanne an
Bin wieder da. Also so halb. Mir geht es zwar gut, aber während meiner Krankheit kam von Stephan freundlicherweise ein Artikel eingeflogen, den ich natürlich heute posten will. Aber zuerst ein herzliches Dank an ihn und auch an alle anderen, die mir so nett gute Besserung gewünscht haben. Genug gelabert, hier Stephans Artikel.
Eine nicht ganz erstgemeinte Betrachtung der Softwareentwicklung
Wie hat mein Urgroßvater, ein leidenschaftlicher Großwildjäger immer so schön gesagt: „Und wenn Du den Löwen nicht aus seinem Versteck locken kannst, dann zünde die Savanne an“.
Natürlich war mein Urgroßvater kein Großwildjäger. Und eigentlich wäre dieser Beitrag auch eher passend für den „Developers Shame Day“, aber es geht hier nicht um Code, sondern um Methoden und Arbeitsweisen.
Und so möchte ich mich outen: Normalerweise versuche ich meine Programme effizient zu halten, Prozesse schlank und sauber abzubilden, fehlertolerant zu programmieren. Nur manchmal will das einfach nicht funktionieren. Der Teufel steckt dann zu tief im Detail, oft sogar in den unzähligen Sonderfällen oder -wünschen die berücksichtigt werden müssen und als Vorgaben nicht veränderlich sind. Manchmal arbeiten andere Systeme nicht so sauber zu, wie sie es tun sollten.
Und leider sind „Sonderfälle“, „schlank, effizient“, sowie „fehlertolerant“ nach meiner leidigen Erfahrung Dinge, die sich ab einer gewissen Größe fast magisch ausschließen. Die Zauberworte lauten „Komplexität“ und „Zeitdruck“.
Das sind die Fälle in denen ich sehr tief einatme und dann programmtechnisch die Savanne in Brand stecke. Da werden nicht einzelne Dateien auf Fehler, Unstimmigkeiten oder Zugriffsrechte hin untersucht, sondern ganze Ordner radikal gelöscht und ganze Prozesse komplett neu und von vorne gestartet. Da werden nicht in den Tiefen irgendwelcher Dateisysteme oder Datenbanken passende Informationsteilchen in einem komplizierten Puzzle gesucht, sondern quasi mit dem Dampfhammer reguläre Ausdrücke über ganze Herden bestehender Dateien gejagt – bis das passende Element dann doch gefunden wurde. Übrigens nicht nur unter PHP, sondern auch unter Java oder anderen Sprachen.
Natürlich könnte man in solchen Fällen ins Detail und die Klärung gehen – aber Hand aufs Herz: Wer hat dazu immer die Zeit? Wer setzt nicht auch ab und zu radikale Methoden ein – auch wenn Festplatten und Prozessoren dann heiß laufen? Oder wie es Rasmus Lerdorf einmal angeblich und wohl augenzwinkernd gesagt hat: „…I’ll just restart apache every 10 requests.“
Man könnte es vielleicht auch lautmalerisch als „Brute-Force Development“ bezeichnen. Vielleicht als neuentdeckte Richtung in der Programmierung mit eigenem Manifest? Mit solchen Punkten wie „Nicht kleckern, klotzen“ oder „Nur das Ergebnis zählt“, „Feinheiten sind Fehlerquellen“, „Kopieren ist sicherer als Verschieben“, „Schönheit löst keine Probleme“?
Wer will das Manifest unterzeichnen? Ich hole schon mal die Fackeln!
Zumindest mir geht es so, dass ich hinterher – wenn wieder etwas Luft ist – einen Teil der Unordnung wieder aufräume. Das gebietet mir mein Schönheitsideal, sorry 😉
Bei einem kleinen, überschaubaren Projekt kann ich das noch nachvollziehen. Aber welche Sicherheit hast du, dass deine neue Implementierung funktioniert? Mit sehr hoher Wahrscheinlichkeit holst du dir mit der neuen Implementierung wieder neue größere Probleme ins Boot.
Ist es nicht sogar wesentlich günstiger und schneller, die Probleme zu analysieren und den Code richtig zu refactoren? Wenn man dann noch davon ausgeht, dass Unit Tests und Functional Tests vorhanden sind, müsste man doch dem Ganzen ratz fatz ein Refactoring unterziehen und die Probleme beseitigen.
@Dennis
Die Holzhammermethode muss nicht bedeuten, dass man unsauberen Code schreibt oder nicht testet.
Man geht eben nur aus unterschiedlichen Gründen einen Weg, der Prozesse abbildet, die nicht fein, filigran und sondern eher „grobschlächtig“ sind. Der Code selbst muss deshalb nicht schlecht sein – auch wenn das zugegeben oft Hand in Hand geht.
Ein konkretes Beispiel: Es gab beim Dateizugriff immer wieder unerklärliche Locks auf einzelne Daten – die Holzhammermethode bestand (unter anderem) darin, dass riesige Datenmengen eben zuerst lokal kopiert wurden. In diesem Falle keine schöne Lösung, der Code war aber dennoch sauber geschrieben, getestet und läuft seit Jahren.
Die Datei-Locks treten übrigens nach wie vor und sind unerklärlich, aber so wenigstens auch ohne Bedeutung 😉
Sowas mache ich eigentlich grundsätzlich nicht. Wenn es länger dauert, dauert es länger – aber an der Qualität zu sparen bringt immer Probleme. Für die Firma – nicht für den Developer.
Ein Postbote für einen Billigversender hat das mal wie folgt formuliert: „Ich liefere den Schrott an und ich hole ihn anschließend auch wieder ab. Für beides werde ich bezahlt.“ – „Wir bauen auf und reißen nieder, haben Arbeit immer wieder.“
Dem Vorgesetzten sage ich Folgendes: man kann nicht alles haben. Features, Zeit, Ressourcen und Qualität sind gegenläufige Ziele. Zieht man an einem Ende des Seils kommt das andere Ende hinterher.
Qualität sollte dabei die einzige Konstante sein, denn Qualität ist es wodurch man sich von der Billigkonkurrenz unterscheidet. Du willst die Quadratur des Kreises auf Biegen und Brechen? Dann hätte ich als projektverantwortlicher Lead Developer gern schriftlich, dass ich dich über die Risiken informiert und du es trotzdem angeordnet hast – gezeichnet mit freundlichen Grüßen Manager Ar. Schmit O.
Überstunden? Erfahrung lehrt: Kein Developer erwägt als erste Option Überstunden: bei angeordneten Überstunden streicht er zuerst Dokumentation und notwendige Sicherheitstests bevor er abends freiwillig länger sitzt. In dem Moment in dem ein Developer nach 18 Uhr noch am Platz ist, ist der Ärger bereits programmiert.
„Nur dieses eine Mal…“ noch während das proklamiert wird leidet bereits des Folgeprojekt, dem notwendige Vorbereitungszeit entzogen wird.
Lieber externe Hilfe holen oder ein einzelnes Projekt aufgeben, als das Gesamtergebnis oder die Firma gefährden.
Entwicklungsphasen und Tests kürzen? Spart momentan ein paar Stunden, erhöht aber schleichend und auf lange Zeit das Geschäftsrisiko und führt zu einem schleichenden Wertverlust des Stammkapitals. Es vergiftet schleichend den wertvollen Code-Pool der Firma aus dem der Schäfer der Herde seine Jünger tränkt, bis ihnen die Wolle ausgeht und sie keine Milch mehr geben. Bei Firmen endet das am Ende stets in der Notschlachtung.
Aus dem Einsparen von Qualität oder Doku folgt fast immer, dass der nächste Entwickler den Code komplett neu schreibt statt ihn wiederzuverwenden, weil er ihn nicht mehr versteht. Schlechter Code verweilt zudem häufig länger als gedacht in der Codebasis und infiziert alle Folgeprojekte, die um den schlechten Code herum arbeiten müssen.
Ohne Test und Doku spart man also 20% Entwicklungszeit zu dem Preis, dass anschließend 100% Entwicklungskosten für’n Arsch sind und bei nächster Gelegenheit komplett neu aufgewendet werden müssen. Schlechte Manager kaufen deshalb immer zweimal: erstmal billig und dann richtig. Das Ergebnis sind Ausgaben von 150%-200% der notwendigen Entwicklungskosten bei dem Versuch 20% einzusparen. Und davon sind nur 80% des Erstaufwandes am Ende billable.
Projektschätzungen sind Risikoschätzungen. Man bewegt sich nicht entlang einer Linie sondern entlang eines Korridors und schätzt nicht den Auslieferungstermin, sondern das unternehmerische Risiko zu einem bestimmten Datum nicht fertig zu werden.
Schlechte Projekte beginnen nicht beim Developer, sondern bei Verkäufer. Indem ein Projekt zu Fixpreisen verkauft wird, ohne das zuvor die Anforderungen konsistent dokumentiert und eine Aufwands- und Risikoschätzung über die Projektleitung eingeholt wurden. Der Fisch stinkt am Kopf zuerst – nicht am Schwanz.
Verkäufer agieren leider zu oft testosterongesteuert – beim Anblick von nackten Geldscheinen wandert das Hirn in den Teil der Firma, der anschließend die Arbeit machen muss.
Und zu guter Letzt: Personal ist wertvoll. Immer wenn man einen Developer verliert, spaziert eine Investition in der Größenordnung eines Kleinwagens aus der Tür. Bei einem Senior oder Lead Developer kann es auch schon mal ein Geländewagen mit Sonderausstattung sein. Und Sie kaufen sich doch auch nicht alle 6 Monate ein neues Auto – oder? Denn DAS halten Sie wiederum für unwirtschaftlich.
Tom, schöner Kommentar 🙂
Tom, danke (!!!) für deinen Kommentar. Du sprichst (schreibst) mir aus der Seele. Habe deinen Text mal in einem eigenen Blogeintrag genutzt.
@Tom
Als eigener Beitrag wäre es abolut Top gewesen!
Aber als Kommentar frage ich mich was das mit dem durchaus ironisch gemeinten Ausgangsbeitrag zu tun hat?
Spätestens wenn der Projektleiter Dir trotz Deiner berechtigten Hinweise ein „MACHEN“ schriftlich gibt darfst Du die Fackeln anzünden.
Mehr Mut und so was als Beitrag, nicht als versteckten Kommentar!!!