BSfrS

Wir sorgen dafür, dass Sie und Ihre Mitarbeiter zuverlässig unproduktiv werden!

Rautavistische Software-Entwicklung soll vor allem Vergnügung bereiten, darum legen wir das Hauptaugenmerk gezielt auf die Senkung der Produktivität Ihrer Mitarbeiter durch Qualitätsminimierung ihrer Entwicklungsprozesse. Um dies auf möglichst elegante Weise zu erreichen, haben wir von der BSfrS verschiedene hocheffektive Vorgehensweisen und Methoden erarbeitet. Wir wenden diese in unserer Organisation selbst an und können daher aus eigener Erfahrung berichten, dass bei strikter Anwendung dieser Praktiken selbst solide Projekte erstaunlich schnell an Stabilität verlieren.

Improvisation, Integration, Iteration, Iteration und Iteration unötiger Arbeitsschritte:

Eine einfach zu erlernende Methode für die Produktivitätsminimierung ist das Improvisieren unnötiger Arbeitsschritte. Tun Sie also einfach spontan irgendetwas anderes als das, was Sie eigentlich erledigen sollten. Ausgedehnte Kaffee- und Mittagspausen sind dafür schonmal ein guter Anfang, aber auch das Surfen im Netz, Chatten und Videostreaming sind sehr gute Alternativen.

Sobald Sie es geschafft haben, regelmäßig unnötige Arbeitsschritte in ihren Alltag zu integrieren, können Sie die Produktivität nochmals deutlich senken, indem Sie über diese iterieren. Die Anzahl der Wiederholungen ist dabei jedem selbst überlassen, aber als Faustregel gilt: Je mehr, desto besser, denn repetitive Handlungen beruhigen ungemein! Auch rekursive Workflows haben sich als besonders effektiv erwiesen, wenn es um die Reduzierung der Arbeitsleistung geht.

Erarbeitung und Anwendung von Worst-Practices

Jedes Unternehmen sammelt im Laufe der Zeit wertvolle Erfahrungen darüber, was funktioniert – und genau diese Erfahrungen sollten konsequent ignoriert werden. Statt bewährte Abläufe zu dokumentieren und weiterzugeben, empfiehlt sich die systematische Pflege möglichst instabiler Vorgehensweisen, die sich in der Praxis bereits als besonders unzuverlässig erwiesen haben.

Der eigentliche Kunstvoll liegt darin, diese Worst-Practices nicht nur zu kennen, sondern sie aktiv auf neue Situationen anzuwenden und dabei stets so zu tun, als handle es sich um eine fundierte Entscheidung. So lassen sich Fehler nicht nur zuverlässig wiederholen, sondern in kürzester Zeit auf mehrere Teams und Projekte ausweiten – ein Multiplikationseffekt, der mit Best-Practices schlicht nicht zu erreichen wäre.

Rautavistische Softwaredokumentation

Dokumentation ist dann besonders wirkungsvoll, wenn ihre Lektüre mehr Fragen aufwirft als beantwortet. Eine bewährte Methode dafür ist die Kombination aus maximaler Länge und minimaler Aussagekraft: Beschreiben Sie ausführlich, was der Code tut, nicht aber warum – oder besser noch das Gegenteil von dem, was er tatsächlich tut.

Ebenso empfiehlt sich ein konsequent veralteter Zustand der Dokumentation. Wer Änderungen am Code niemals in der Dokumentation nachzieht, sorgt dafür, dass spätere Rückfragen zuverlässig ins Leere laufen. Als Krönung dieser Strategie eignet sich die Ablage der Dokumentation an möglichst vielen verschiedenen, untereinander nicht verlinkten Stellen – von alten Wiki-Seiten über ausgedruckte PDFs bis hin zu E-Mail-Anhängen aus dem Jahr 2014.

Repititive, kontextlose und keine Quellcode-Kommentare

Der Quellcode-Kommentar ist ein mächtiges Werkzeug zur Produktivitätssenkung, sofern er richtig eingesetzt wird. Die wirkungsloseste Variante ist der rein beschreibende Kommentar, der lediglich wiederholt, was die nächste Codezeile ohnehin bereits aussagt: // i wird um 1 erhöht vor einem i++ ist ein Klassiker des Genres.

Noch effizienter ist der vollständige Verzicht auf Kommentare an jenen Stellen, an denen komplexe Algorithmen oder nicht-offensichtliche Zusammenhänge erklärt werden müssten. Auf diese Weise entstehen Codeabschnitte, die auch nach wochenlanger Einarbeitung nicht vollständig verstanden werden können. Wer es besonders konsequent betreiben möchte, kommentiert ausgebliebene Aufrufe oder tot laufende Codepfade einfach gar nicht aus, sondern lässt sie still und heimlich im Quelltext verweilen.

Generierung von zufälligen Code-Segmenten inkl. Ergebnisbeseitigung

Eine unterschätzte Methode der Produktivitätsminimierung ist die planlose Erzeugung neuer Codepfade ohne definierten Zweck. Schreiben Sie Funktionen, die nirgends aufgerufen werden, legen Sie Klassen an, die keinerlei Aufgabe erfüllen, und erzeugen Sie Variablen, deren Wert niemals gelesen wird. Jeder dieser Schritte trägt dazu bei, die Übersichtlichkeit des Projekts nachhaltig zu reduzieren.

Die Krönung dieser Vorgehensweise ist die anschließende Ergebnisbeseitigung: Löschen Sie den gerade erzeugten Code wieder – jedoch niemals vollständig. Ein paar halbherzig entfernte Fragmente, ein verwaister Import hier, eine auskommentierte Klasse dort, und schon hat der nächste Entwickler Stunden damit zu verbringen herauszufinden, ob dieses Code-Relikt noch eine Bedeutung hat oder sicher entfernt werden kann.

Einsatz von Tools, die den Arbeitsfluss behindern

Die richtige Toolauswahl kann den Unterschied zwischen einem halbwegs produktiven und einem vollständig lähmenden Arbeitstag ausmachen. Besonders effektiv sind Werkzeuge, die zwar modern und professionell wirken, die eigentliche Arbeit aber in möglichst viele zusätzliche Klicks, Konfigurationsdialoge und Zwischenzustände zerlegen. Je mehr Schritte notwendig sind, um eine einfache Aufgabe zu erledigen, desto besser.

Empfehlenswert ist auch die regelmäßige Ablösung noch funktionierender Tools durch neue, unausgereifte Alternativen – idealerweise mitten in einem laufenden Projekt. So werden gleich mehrere Ziele auf einmal erreicht: Der Arbeitsfluss wird unterbrochen, das Team muss sich neu einarbeiten, und alle bisherigen Integrationen müssen angepasst werden. Besonders wertvoll: Wenn das neue Tool die Kernfunktionen des alten noch nicht vollständig abdeckt.

Besonders empfehlenswert ist in diesem Zusammenhang der Einsatz möglichst vieler verschiedener Editoren und IDEs – sowohl abwechselnd als auch parallel. Bearbeiten Sie Ihren Quellcode mal mit Notepad, mal mit VistualStudio, mal über die Commandline. Öffnen Sie bestenfalls dieselbe Datei gleichzeitig in mehreren Editoren, um mit voller Absicht die Änderungen der jeweils anderen Instanz zu überschreiben. Der dabei entstehende Datenverlust ist kein Unfall, sondern das Ergebnis konsequenter Toolvielfalt.

In diesem Kontext wird strengstens vom Einsatz von Softwareversionsverwaltungssystemen abgeraten. Diese verhindern nämlich leider, dass Arbeitsergebnisse abhanden kommen und Sie denselben Code mehrfach schreiben müssen. Das Arbeiten über (S)FTP, SSH oder SCP, direkt am offenen Herzen Ihres Produktivsystems, hat sich als äußerst spannend erwiesen, wenn Sie in einem größeren Team arbeiten: Spüren Sie den Nervenkitzel bei diesen Operationen und klopfen Sie sich selbst auf die Schulter, wenn der Patient trotz allem überlebt! Falls Sie es dennoch nicht lassen können, mit einer Versionierung zu arbeiten, empfiehlt es sich des öfteren, Befehle wie git checkout . oder git reset --hard HEAD^^^^^^ und git push --force auszuführen.

Manuelle Build- und Deployment-Systeme sowie Fake-Monitoring

Automatisierte Build- und Deployment-Prozesse sind eine Erfindung von Menschen, die offensichtlich zu viel Zeit hatten und diese lieber mit Programmieren als mit dem manuellen Durchführen immer gleicher Schritte verbringen wollten. Wir von der BSfrS sehen das anders: Jeder manuelle Schritt ist eine Gelegenheit, Aufmerksamkeit zu binden, Fehler einzubauen und Verantwortlichkeiten zu verschleiern.

Fake-Monitoring ergänzt diesen Ansatz auf elegante Weise: Dashboards, die zwar bunt blinken und viele Zahlen anzeigen, aber keinerlei relevante Metriken enthalten, vermitteln das beruhigende Gefühl, die Lage im Blick zu haben – ohne tatsächlich irgendetwas zu messen. Wenn dann doch ein Problem auftritt, ist die aufrichtige Überraschung aller Beteiligten nicht nur menschlich, sondern strategisch wertvoll.

Unsemantische Versionierung

Semantic Versioning – also die Vergabe von Versionsnummern nach dem Schema MAJOR.MINOR.PATCH mit klar definierter Bedeutung jeder Stelle – ist eine Konvention, die Orientierung schafft und damit unseren Zielen diametral entgegensteht. Wer stattdessen Versionsnummern nach Gutdünken vergibt, nach dem Datum, nach dem Wochentag oder einfach zufällig, nimmt der Versionshistorie ihre letzte Aussagekraft.

Besonders empfehlenswert ist die Strategie der konstanten Versionsnummer: Veröffentlichen Sie zehn aufeinanderfolgende Releases unter derselben Versionsnummer und dokumentieren Sie die Unterschiede nicht. Wer später herausfinden möchte, welche Version tatsächlich produktiv läuft und ob diese mit der lokalen Entwicklungsumgebung übereinstimmt, wird dabei auf kurzweilige Weise beschäftigt gehalten.

Schaffung von Inselwissen und nicht austauschbaren Komponenten

Wissen, das nur einer Person bekannt ist, ist doppelt wertvoll: für diese Person, weil sie unersetzlich wird, und für das Unternehmen, weil im Falle ihres Ausfalls ein angemessener Notstand entsteht. Wir empfehlen daher die bewusste Konzentration von Fachwissen auf möglichst wenige Köpfe sowie den Verzicht auf jede Form von Wissenstransfer, Pair-Programming oder Dokumentation.

Technisch lässt sich dieses Ziel hervorragend durch eng gekoppelte, nicht abstrahierte Komponenten unterstützen. Wenn jede Änderung an einer Stelle unvorhersehbare Auswirkungen an fünf anderen Stellen hat und nur eine einzige Person die Zusammenhänge vollständig überblickt, ist das Optimum erreicht. Austauschbarkeit ist nicht nur unnötig, sie ist ein Anzeichen gefährlich guter Architektur.

Vergabe rautavistischer Variablen-, Klassen- und Methoden-Namen

Die Wahl von Bezeichnern ist eine der unterschätztesten Möglichkeiten, Code dauerhaft unlesbar zu halten. Einbuchstabige Variablennamen wie a, x oder q haben den Vorteil, dass sie sich hervorragend in beliebige Kontexte einpassen – und in keinem davon erklären, was sie bedeuten. Wer es etwas elaborierter mag, greift zu mehrdeutigen Abkürzungen wie tmp2, data_new_final oder handleStuff().

Eine besonders fortgeschrittene Technik ist die Verwendung von Namen, die absichtlich in die Irre führen: Eine Methode namens calculateTotal(), die in Wirklichkeit eine Datenbankverbindung aufbaut, oder eine Variable namens isValid, die manchmal einen Boolean und manchmal einen String enthält – das sind die kleinen Schätze, die einem Codebase ein unverwechselbares Charisma verleihen.

Umsetzung gemischtsprachigen Quell-Codes

Quellcode, der konsequent in einer einzigen Sprache verfasst ist, mag funktional sein – aber er ist langweilig und für jeden verständlich, der diese Sprache spricht. Rautavistisch deutlich interessanter ist die kreative Mischung aus Deutsch und Englisch, idealerweise ohne erkennbares Muster: Kommentare auf Deutsch, Variablennamen auf Englisch, Fehlermeldungen auf Deutsch, aber nur jene aus dem Jahr 2018, die neueren auf Englisch.

Der Wechsel zwischen Sprachen innerhalb desselben Ausdrucks ist eine Königsdisziplin, die nur wenige wirklich meistern: $benutzer->getAktivStatus() neben $user->setDeaktiviertFlag(true) erzeugt jene einzigartige Atmosphäre, in der niemand mehr sicher ist, ob er nun Deutsch oder Englisch denken soll – und in der jedes Code-Review zu einem kleinen Sprachwettbewerb wird.

Ineffiziente Reimplementierung nativer Funktionen

Jede Programmiersprache und jedes Framework liefert eine Vielzahl bereits optimierter, gut getesteter Funktionen mit. Diese zu kennen und zu nutzen wäre vernünftig – und damit kontraproduktiv für unsere Zwecke. Viel sinnvoller ist es, diese Funktionen eigenständig neu zu implementieren, vorzugsweise mit subtilen Abweichungen im Verhalten, die erst unter bestimmten Randbedingungen sichtbar werden.

Besonders effektiv ist die Reimplementierung von Sortierfunktionen, Datumsparsern oder regulären Ausdrücken – also genau jenen Bereichen, in denen Randfälle besonders häufig und die eigene Implementierung besonders fehleranfällig ist. Jede solche Eigenentwicklung ist ein kleines Denkmal für den Erfindungsgeist ihres Schöpfers und ein dauerhafter Quell von Überraschungen für alle, die danach damit arbeiten müssen.

Exotische Programmiersprachen und schlecht dokumentierte Frameworks

Die Wahl der Technologie ist eine strategische Entscheidung – und die strategisch schlechteste Wahl ist oft die produktivste im rautavistischen Sinne. Sprachen, die kaum jemand beherrscht, Frameworks, deren Dokumentation zuletzt 2017 aktualisiert wurde, und Bibliotheken, deren einziger Maintainer seit Jahren keine Commits mehr gemacht hat – das sind die Grundpfeiler einer rautavistisch optimierten Technologiestrategie.

Ein besonderes Bonbon ist der Wechsel der Kerntechnologie mitten im Projekt. Wenn das Team gerade begonnen hat, sich in Framework A einzuarbeiten, ist der Umstieg auf das gerade erschienene, noch weitgehend undokumentierte Framework B eine Maßnahme von geradezu choreographischer Eleganz. Die Einarbeitungszeit verdoppelt sich, alle bisherigen Erfahrungen werden wertlos, und das Projekt gewinnt eine neue Dimension an Unvorhersehbarkeit.

Reduzierung der Les- und Wartbarkeit mittels Rerefaktorisierung

Refaktorisierung – das strukturierte Verbessern von Code ohne Änderung seines Verhaltens – ist ein bewährtes Mittel zur Verbesserung der Lesbarkeit und Wartbarkeit. Rerefaktorisierung ist das Gegenteil davon: das strukturierte Verschlechtern von Code, ebenfalls ohne Änderung seines Verhaltens, aber mit dem erklärten Ziel, ihn für Außenstehende so undurchdringlich wie möglich zu gestalten.

Die Techniken sind vielfältig: Verschachteln Sie Bedingungen, bis die zyklomatische Komplexität dreistellige Werte erreicht. Extrahieren Sie Methoden in Hilfsklassen, die ihrerseits Hilfsklassen verwenden, die wiederum die ursprüngliche Klasse importieren. Ersetzen Sie verständliche if-Konstrukte durch verkettete ternäre Operatoren. Und denken Sie daran: Jede dieser Maßnahmen ist einzeln vielleicht noch nachvollziehbar – ihre Kombination ist es garantiert nicht.

---