Sollte eigentlich ein Allgemeinplätzchen sein, aber in der Realität…
1 „Gefällt mir“
Zugegeben, ich habe es (noch?) nicht bis ganz zuende gelesen, aber … der Grund dafür ist, dass das, was da bisher steht, nach Binsenweisheiten klingt.
Einerseits habe ich auch schon zu Leuten, die mir „weisungsbefugt“ waren, metaphorisch gesagt: „Du gibst immer Vollgas. Aber wenn man Vollgas gibt, drehen die Räder durch, und dann kommt man langsamer vorwärts“. Aber die genauen Ausformulierungen dort sind entweder Pauschalplätze, „Truisms“ oder verblendet-idealistisch wirkendes Wunschdenken. Morgen ist die Deadline. Features X und Y wurden implementiert, Feature Z fehlt noch. Schreibt man Tests für X und Y, um sicher zu sein, dass da keine Fehler drin sind, oder dengelt man noch Feature Z dazu? Die Antwort ist klar. Wer sollte da wem was in die Tasche lügen?
Ich stimme zumindest auf der Ebene des Titels und der Allgemeinplätze zu: Ich denke, dass man, wenn man gute Software entwickeln will, man dafür in erster Linie Zeit braucht. Jeder einzelne Prozessschritt, der bewirkt, dass Software auch nur potentiell „gut“ sein könnte, braucht Zeit. Überlegen und Planen. Gewissenhaft ausimplementieren. Refactorn. Testen. Dokumentieren. Und wenn wenig Zeit da ist, dann beruft sich der Chef auf den (hier bewußt aus dem Zusammenhang gerissenen) Satz, den der Autor im Text selbst geschrieben hat:
Waste is anything you produce that has no business value.
Und das ist hier Planung, Refactoring, Testing und Dokumentation 
Das ist ja das Problem, dass man noch nicht mal Binsenweisheiten folgt.
Tja BWL erstes Semester (kein Scherz, keine Ironie, kein Sarkasmus):
- Mitarbeiter müssen immer zu 100% ausgelastet sein
und auch mein absoluter Liebling das ich auch dem Thema zuordnen möchte:
- Wenn ein Mitarbeiter ‘T’ Tage für eine Aufgabe braucht, dann benötigen ‘X’ Mitarbeiter
T/X = T_neu Arbeitstage
Achja und:
- Innovationen sind ein hohes finanzielles Risiko
zum Thema der 80/20 Regel von Google.
Wenn man Mitarbeiter als “Ressourcen” sieht, braucht man sich auch nicht über “Dienst nach Vorschrift” wundern.
Ja, der Klassiker: 9 Frauen brauchen für ein Baby einen Monat. Mit sowas wie Amdahlsches Gesetz – Wikipedia oder Gustafsons Gesetz – Wikipedia braucht man da nicht zu kommen.
Nochmal deutlicher: Mir ist nicht ganz klar, was die Kernaussage des Artikels sein soll - zumindest nicht, was hinausgeht über das Gebetsmühlenartig an „Verantwortliche“ gerichtete: „Gebt uns Zeit, wenn ihr vernünftige Ergebnisse wollt!!!111“.
Es gibt da eben viele Schwierigkeiten un Unwägbarkeiten:
- Ein „guter“ Entwickler kann vielleicht in 3 Tagen etwas implementieren, wo ein „schlechter“ Enwickler 3 Wochen aufwenden würde, um im Endeffekt das gleiche Ergebnis zu erreichen
- Jeder Entwickler kann („Glück“ haben und) innerhalb von 3 Tagen einen unüberlegten „first shot“ raushauen, der in vieler Hinsicht („zufällig“!) das gleiche ist, wie das, was nach 3 Wochen Planung rausgekommen wäre (oder sogar besser - ja!)
- Gerade bei der Softwareentwicklung ist es so: Ein „guter“ Entwickler ist „besser“ als 5 mittelmäßige. Der Beitrag einer einzelnen Person zum „Asset“ („Gesamtwert“) der Codebasis kann negativ sein. Wie eine ehemalige Kollegin mal gesagt/zitiert hat:
Es gibt 4 Arten von Menschen.
Die schlauen Fleißigen.
Die schlauen Faulen.
Die dummen Fleißigen.
Die dummen Faulen.
Und am schlimmsten sind nicht die dummen Faulen, sondern die dummen Fleißigen.
In dem Artikel sind nicht wirklich Ziele beschrieben, abgesehen von vagen, nicht (oder nicht direkt) quantifizierbaren Dingen wie „bessere Software“, die „schneller“ entwickelt werden soll, indem man „langsamer“ arbeitet (und wenn wir hier Bullshit-Kung-Fu spielen würden, würde ich jetzt auf SMART (Projektmanagement) – Wikipedia verweisen 
). Die Wege, auf denen diese Ziele erreicht werden sollen, sind dann beschrieben mit Sätzen wie
We use hexagonal architecture to active loose coupling and high cohesion at high level design of the system.
Mal im Ernst: Wer auch nur den Hauch einer Vorstellung davon hat, was mit diesem Satz gemeint sein könnte, braucht ihn nicht zu lesen. Jemand der ihn lesen müßte, versteht ihn nicht.
Auch mal vage nachgefragt: Findet jemand, dass das ein „guter Artikel“ ist?
Kann der Chef Programmieren? Wenn ich mein Auto in die Werkstatt bringe interessiert mich auch nicht wie da die Abläufe geplant werden, wo die Kabel im Motorraum gezogen werden, ob das Auto einmal um den Hof gefahren wird oder ob es für die Bauteile eine Anleitung gibt. Ich will nur hinterher sicher damit auf die Autobahn. Wenn der Mechaniker mir sagt er braucht zwei Tage um den Motor zu wechseln, dann ist das so.
Die Artefakte haben zwar keinen direkten Businesswert, beeinflussen aber indirekt den Wert/die Qualität des Produkts. Daher sind sie nicht automatisch waste. Zu viel von jedem kann natürlich Verschwendung sein. 12 Monate für den Austausch einer Autobatterie sind ja auch zuviel.
Den Artikel an sich finde ich lesenswert. Mich stören die harten Aussagen „mach genau das“, wo ich mich als Leser frage „warum?“ (z.B. „Fix the bugs if you need 30 mins or less to fix them“, „Additionally, use 20% of your time eliminating technical debt.“). Viele Faustregeln machen sicherlich Sinn, sind aber auch stark Kontextabhängig. In einer Steuersoftware für eine Rakete würde man hoffentlich mehr Zeit für Bugfixes einplanen als in dem Controller für eine Popcornmaschine. Außerdem setzt der Artikel viele Dinge wie TDD, Git Workflow, Hexagonale Architektur etc. voraus die nicht überall präsent sind.
Die Frage (und die möglichen Antworten, „Ja“, „Nein“, und alles, was dazwischen liegt 
) erscheint mir hier nicht relevant. Jeder kennt doch die Konversationen, die ich hier ein wenig überspitzt (aber bei weiten nicht so überspitzt, wie man im ersten Moment meinen könnte) skizziere:
- Chef: Es sind noch zwei Wochen bis zur Deadline
- Programmierer: Das Feature zu implementieren dauert vier Wochen
- Chef: Dann plane doch einfach, schon in einer Woche fertig zu sein. Dann hast du noch eine Woche Puffer
- Programmierer:
(… 
…)
Das mit der Autowerkstatt… Autos sind zwar tolle, bildliche Vergleiche, für vieles, was mit Programmieren zu tun hat. Aber vielleicht passt das hier deswegen: