Programmierer-Ethik – Test geschrieben – Bugs gefunden – Kündigung abgegeben

Wir Programmierer sollten uns mal über das Thema „Programmierer-Ethik“unterhalten. Also ab wann muss man als Programmierer „Nein“ sagen, weil die Qualität des Projekts das Geschäftsmodell des Kunden gefährdet. In einem meiner letzten PHP-Jobs, als fest angestellter Entwickler, habe ich für eine große Symfony E-Commerce-Applikation automatisierte Frontend-Tests mit dem Codeception Framework für Formulare geschrieben. Die haben auch schnell fehlende Validierungen in Pflichtfeldern von Formularen gefunden. Am Ende waren tatsächlich u.a. alle E-Mail Felder kaputt. Absolut kritisch und geschäftsschädigend für den Geschäftsprozess. Der Fehler war auch schon sehr lange im Live-System, aber es ist nicht aufgefallen. Ich habe ihn in den ersten Stunden Onboarding-Phase für das Projekt gefunden. Da der aktuelle Task, für eine Erweiterung des Formulars und meine Einarbeitung, in dem Falle nicht in der gewünschten Zeit fertig wurde bat man mich zum ersten Personalgespräch. Ich hätte mich weniger um Tests, als mehr um die Fertigstellung des aktuellen Tasks kümmern sollen. So war das Ticket nicht fertig und es konnte noch nicht abgerechnet werden. Einige Wochen später gab es dann das zweite Gespräch. Hier wurde ich dann gekündigt. Wegen der Tests und meinem Anspruch an Softwarequalität. Genau dafür war ich übrigens ursprünglich eingestellt worden. Bereits beim Verlassen des Gebäudes stellte sich ein gutes und befreiendes Gefühl bei mir ein. Schon am nächsten Tag hatte ich ein Vorstellungsgespräch. A Coders life? – Maybe.

Motivierte Teams mit einem hohen Anspruch an Softwarequalität suchen neuen Teamplayer

Falsche Aussagen in Stellenausschreibungen sollten strafbar sein. Und vieles andere auch verboten und auf jeden Fall veröffentlicht werden. Ich war also mal wieder auf alles reingefallen und zu einer Agentur gegangen. Tolles Gehalt, ICE-Ticket, schicke Lage und Office. Und dazu ein Haufen junger und netter Leute. Mein Arbeitsschwerpunkt „Testing und Refactoring mit dem Aufbau eines internen Know-How-Transfers“. Also Code Reviews, Pair Programming und interne Workshops. Mein persönlicher Traum. Wer kann da schon Nein sagen. Und dann stellte sich aber doch schnell eine gewisse Ernüchterung ein. Frustrierte Mitarbeiter. Lokale Entwicklungsumgebungen konnten überhaupt nicht aufgesetzt werden und die „Teams“ bestanden aus einzelnen Entwicklern auf dem jeweiligen Projekten, die mich einarbeiten, das Schlimmste abwenden und neues implementieren sollten. Keine Zeit für Onboarding war eingeplant. Dafür hatte man ja schließlich auch einen Senior Developer eingestellt. Denn die brauchen das ja bekanntlich nicht. In diesem Arbeitsumfeld waren meine Ideen gerade völlig falsch am Platz. Aber ich nahm die Herausforderung an, denn schließlich ist Legacy Code mein Geschäft und ein Turnaround mehr als nur ein Unit Test.

Automatisierte Tests brachten mir viel Geschwindigkeit und fanden leider auch ein ganzes Bugnest

Bei meiner ersten Aufgabe handelte sich im eine E-Commerce Anwendung für den B2B-Bereich. Es gab also zahlreiche unterschiedliche Berechtigungen und Rollen. Einige können bestellen, andere Bestellungen freigeben und auch sonst haben solche Applikationen ein wirklich komplexes Rollenmanagement. Das ist gerade dann der Fall, wenn es um die Abbildung von komplexen Konzernstrukturen geht. Eine solche Software braucht eine sehr gute Planung, Projektmanagement und Durchführung. Das kann eben nicht am Ende einfach mal von ein oder zwei Entwicklern gebastelt werden, bis es einfach fertig ist. Es ist in dieser Applikation sehr aufwändig manuelle Tests durchzuführen, da man sich ständig mit unterschiedlichen Usern ein- und ausloggen muss. Daher hatte ich von Anfang an mit Codeception Acceptance Tests gebaut, die u.a. Methoden loginAsAdmin(), loginAsConcern() etc. abbilden konnten. So konnte ich Bugs und Features schnell abbilden und für meine aktuellen Tasks deren richtige Funktion gewährleisten. Das hat die Kollegen von der Entwicklung schon richtig neidisch gemacht. Vor allem, weil es innerhalb weniger Stunden erledigt war. Die Einführung von Tests war also die Grundlage zur effizienten und schnellen Arbeit. Das kam bei den Entwicklern sehr gut an, das Management und die Projektmanager hat das leider von Anfang an gestört. Es gab einfach zu viele Bugs, die jetzt auch gefunden wurden. Das sollte der Kunde aber lieber nicht sehen und wissen. Es wurde also vertuscht. Eine Frage der Programmierer-Ethik. Wer schützt uns davor, solche Jobs ausführen zu müssen?

Der Schaden liegt beim Kunden – ein nettes Startup das 15% Budget extra für Softwarequalität zahlt – Programmierer-Ethik ist wichtig für die IT Branche

Es gibt nicht nur die uneinsichtigen und beratungsresistenten Kunden aus der Hölle. Ganz im Gegenteil. Kunden, die mit ihrer Applikation Geld verdienen wollen und zuverlässige Software brauchen, sind gerne bereit mehr Geld zu zahlen. Hier hat sich im Markt eine Größe von 10-15% des Auftragsvolumens etabliert. Das Geld soll für Testing und Refactoring verwendet werden. Genau für diese Aufgabe wurde ich als Senior PHP-Developer in das Projekt geholt. Leider wurden die Stunden im Hintergrund einfach mit dem gegebenen Projektchaos durch Legacy Code verrechnet. Im Klartext – Tests und Refactoring bezahlt und Bugs ganz bewusst ausgeliefert. Und so wurde es intern auch kommuniziert. Ein ganz klarer und vorsätzlicher Betrug. Also wurde weiterhin nichts im Bezug auf Refactoring und Testing unternommen und so weitergemacht, wie bisher. Klar das hier meine Position als PHP-Entwickler mit dem Fokus „Testing und Refactoring“ schnell gefährdet war. Von der eigenen Motivation einmal ganz zu schweigen. Das ging natürlich auch stark gegen meine persönliche Programmierer-Ethik. Und genau da habe ich bekanntlich auch überhaupt keinen Bock mehr drauf. Doch die eigentliche Katastrophe hatte der Kunde. Da hatte ich echt Mitleid mit dem sympathischen Startup. Junge Leute, die sich ihren Traum aufbauen und fremdes Kapital durch Investoren mit aufwändigen Pitches an Land gezogen haben. Das ist eine außergewöhnliche Leistung, die ich sehr respektiere und bewundere. Sie beschäftigen sogar selber schon angestellte Mitarbeiter und wenden sehr viel Energie auf, um richtig zu skalieren. Das konnte ich mir nicht länger ansehen und hatte Aufgrund dieser Umstände bereits selber innerlich gekündigt.

Wir brauchen Know-How und GitLab Pipelines

Vergleichbare Projektsituationen kennt jeder. Das hat auch wenig mit der IT zu tun. Natürlich ist das Thema größer und aktueller denn je. Dabei ist es in dem hier beschriebenen Projekt nicht schwer technische Grundlagen für gute Softwarequalität und agile Arbeitsmethoden einzuführen. Beides hat als Grundlage die Wahrheit. Erste Schritte können hier schnell gegangen werden und verbessern die Situation sofort. Ein Codestandard und statische Codeanalyse mit PHPStan in einer GitLab Pipeline sind hier eine nachhaltige Basis. Das kann von uns mit einem PHP-Training gemeinsam innerhalb von 5 Tagen aufgesetzt werden. Aber was hindert uns Entwickler daran, diese Woche nicht einmal gemeinsam zu investieren. Andere Prozesse und auch die Kommunikation haben hier bereits viele Stunden in Anspruch genommen. Nur damit der Zustand belegt wird und das Budget für diese eine Woche freigegeben werden kann. Das bedeutet jemand muss dem Kunden schonend beibringen, dass die ganz neue Software bereits Wartung benötigt und nicht auf nachhaltige Softwareentwicklung ausgelegt ist. Das wurde aber ganz anders Versprochen. Der Grund ist auch fehlendes technisches Know-how. Und das ist die Wahrheit, die keiner hören und aussprechen will. Es läuft doch. Und es läuft solange, wie wir das immer wieder fixen. Mit der heißen Nadel, der Brechstange, dirty Hacks und vielen Dingen, die man so sonst nie machen würde. Aber wollen wir in so einer Welt Leben und ist es das, was wir mit gutem gewissen als Profis verkaufen wollen? eine ethische Frage.

Change the Company or change the Company – Gute Arbeit wird immer bezahlt

Der IT Markt wächst. Auch PHP-Projekte werden weiter stark nachgefragt. Dazu gibt es ein Nachwuchsproblem. Aus meiner persönlichen Erfahrung mit einem Nervenzusammenbruch möchte ich helfen. Never Code Alone steht für Open Source, Software Craftsmanship und Leidenschaft bei der Arbeit. Tatsächlich bietet die aktuelle Situation, und gerade auch durch Corona, grosse Chancen. Auf einmal ist hier was reingedonnert. Und hier können sich einige Agenturen nur sehr schwer anpassen. Auch ich habe dieses Jahr schwer gelitten. Aber ich bin auch nur einer. Also bei TESTIFY sind wir jetzt zu dritt und auch bei Webdesign mit Never Code Alone. Aber das sind Freelancer. Und Freunde. Mit Festangestellten und Miete und allem Zip und Zapp sieht die Geschichte schon ganz anders aus. Und auf einmal kommen Kunden auch mit remote Workern und Video Calls klar. Also einfach mal einen vereinbaren. Am Ende können wir uns immer noch unsere Jobs aussuchen und haben das Recht und vielleicht auch die Pflicht Nein zu sagen.

Ich will das nicht mehr – kreative Jobs sind ohne Spaß nicht zu bewältigen

Programmieren ist keine leichte Arbeit. Die Anforderungen an Projekte wachsen sehr schnell. Oft werden eine Vielzahl von Features bestellt und implementiert. Alle müssen immer insgesamt lauffähig bleiben. In unserer komplexen Welt eine Herkulesaufgabe. Der stellen wir uns gerne. Aber wiederkehrende und nervige Prozesse halten uns von den echten Heldentaten ab. Updates, Refactoring, Testing und Deployments. Mir persönlich machen genau die richtig viel Spaß. Und das hilft uns allen weiter. Wenn wir machen, was uns Spaß macht, dann arbeiten wir effizienter und verbessern mit unserer Leidenschaft immer mehr unsere Projekte. Und das wichtigste, es macht einfach mal wieder richtig Bock morgens aufzustehen.

Wenn du als Entwickler Schuld bist und keine Fehler machen darfst

Was macht uns genau an der Arbeit eigentlich krank. Oder besser gefragt, macht schlechte Softwarequalität wirklich krank? Dieser Frage gehe ich schon seit einigen Jahren nach. Für mich ist das völlig klar. Schwer lesbarer Code macht Kopfschmerzen. Allein das ist eine unnötige und hohe mentale Belastung. Wird man dabei noch unterbrochen und muss sich jedes mal wieder in den Code „eindenken“, kostet das zu viel Kraft. Aber lasst uns jetzt nicht noch auf Komplexität und Dominoeffekte (Side-Effekte) eingehen. Eines ist mir im Laufe der Jahre als Entwickler völlig klar geworden. Unter Druck entstehen keine Diamanten, sondern Opfer. Und das ist in unserer Branche und Situation absolut unnötig und total absurd. Ich will mich aber nicht ständig wiederholen. Druck kann von außen kommen. „Der Kunde will das heute noch haben“. Und Druck kann sich ein Entwickler auch selber machen. „wenn ich das Feature jetzt nicht liefern kann, dann bin ich es nicht mehr wert“. In dem Kontext sehe ich auch nicht gehaltene Absprachen, wie beispielsweise klare Vereinbarungen in einem Sprint. Das war bisher mein Blick. Bei TESTIFY hat mich allerdings jetzt eine Agentur angesprochen, bzw. ihr Team, mit dem Hinweis „sie hätten aktuell Angst etwas auszurollen“. Angst ist sicherlich deutlich heftiger, als Druck. Wenn es euch schlecht geht. Sprecht mich persönlich oder Susanne Neunes aus unserem Netzwerk als Therapeutin an. Wir helfen gerne und diskret.

Schlechte Softwarequalität und Legacy Code ist in jeder Projektgröße allgegenwärtig

„Ja im Agenturgeschäft kann ich mir das ganz gut vorstellen“ so eine durchaus verbreitete Meinung über schlechte Zustände. Weil die immer billiger sein müssen, als die anderen. Das kann ich auch so durchgehen lassen. Das wir uns gegenseitig im Markt drücken lassen ist bekannt, absurd und allgegenwärtig. Aber damit ist es bei Teams, die Software für sich selber produzieren, doch nicht automatisch besser. Für Softwarequalität braucht man eine ganze Menge Know-how und Passion. Hier arbeiten aber zum teil Senior Developer seit über 10 Jahren im eigenen PHP-Framework und wissen nicht mal, wie Composer funktioniert. In welcher Arbeitsbedingung man jetzt mehr Know-how aufbaut und sich wohler fühlt ist, denke ich, eine Frage der eigenen Persönlichkeit. Ich kenne beide Seiten mittlerweile echt gut. In Agenturen kann ich mit neuer und aktueller Software frische Projekte starten. In Software Monoliten dagegen hängt man gerne mal zwei Versionsnummern hinterher. Auf beiden Seiten gibt es große technische Schulden. Die können nur mit automatischen Prozessen abgebaut werden. Sie sind eben der Schössel. Und wenn man dafür keine Zeit hat, dann steckt man eben bis zum Hals im Legacy Sumpf. Ob in einem oder in 10 Projekten.

Fazit Programmierer Ethik – Agenturen mit Wasserkopf werden große Probleme bekommen

Die Artikel hier soll nicht pauschal über Agenturen, sondern über Legacy Code richten. Man kann mit viel weniger Aufwand und den richtigen technologischen Entscheidungen richtig gute Software produzieren. Dabei geht es gar nicht darum billiger zu sein, denn in der IT muss einfach permanent in die Zukunft investiert werden. Das heißt konkret in Know-how und Innovationen. Automatisierte Prozesse sparen viel Zeit und machen eine zuverlässige und stressfreie Entwicklung möglich. In chaotischen Arbeitsbedingungen kann man nur noch unter Druck mit viel unbezahlter Zeit zuverlässig eine Software auf dem letzten Rad live bringen. Darauf hat auch kein Programmierer und keine Programmiererin mehr Bock. Wir wollen gute Arbeit abliefern und als Profis wahrgenommen und respektiert werden. Passiert das nicht wechseln wir auch für besseres Geld ganz einfach den Job. Und wir wissen immer besser, wo es gut ist. Macht Community-Events statt Stellenausschreibungen. Schickt glückliche Entwickler auf Bühnen vor andere Entwickler. Aber vor allem hört auf für gutes Geld schlechte Ware zu liefern. Denn das gefährdet uns alle und bringt niemanden nach vorne. Ich habe gelernt „Nein“ zu sagen und seitdem geht es mir einfach viel besser.