Programmierung: Softwareentwicklung ist sehr subjektiv
Dieser Text ist eine Übersetzung. Das Original des Entwicklers Vadim Kravcenko ist hier zu finden(öffnet im neuen Fenster) .
Die meisten Menschen kennen das Gefühl: Man fängt bei einer neuen Firma an und hat das Bedürfnis, alles umzuschreiben. Das Unding, das die neuen Teammitglieder vor einigen Jahren fabriziert haben, schmerzt. Natürlich weiß man selbst es besser und würde beim Entwickeln dieses Features auf bewährte Verfahren setzen. Oder?
Wahrscheinlich. Im Laufe der Jahre habe ich allerdings gelernt, dass auch bewährte Verfahren, die so genannten Best Practices, immer subjektiv sind. Jedes Unternehmen hat andere Regeln, die befolgt werden müssen und im jeweiligen Kontext auch sinnvoll sind. Beim Verlassen der Firma übernehmen wir manche dieser Regeln als eigene "Best Practices".
In der Softwareentwicklung gibt es jedoch keinen Goldstandard. Alles, was wir tun, ist meinungsgeprägt und funktioniert nur für uns. Heraus kommt ein Ungetüm aus Teilen unterschiedlicher Paradigmen, die uns selbst, und nur uns selbst, dabei helfen, effizient zu sein.
Meinungsgeprägte Verfahren
Grundsätzlich gibt es sehr viele unterschiedliche Methoden, Software zu entwickeln:
- die testgetriebene Entwicklung (Test-Driven Development, TDD) – der heilige Gral der Entwicklung, den alle zu erreichen versuchen
- das Acceptance Test-Driven Development (ATDD) – eine Variation der testgetriebenen Entwicklung mit einem stärkeren Fokus auf der Businessperspektive
- die verhaltensgetriebene Entwicklung (Behavior-Driven Development) – eine weitere Variante, deren Schwerpunkt darauf liegt, ein gemeinsames Verständnis für eine Beschreibung zu schaffen, wie der jeweilige Softwarebestandteil funktionieren soll
- die beispielgetriebene Entwicklung (Example-Driven Development) und Story-TDD – weitere Varianten, mit denen festgelegt werden kann, was eine Software können muss und wie das getestet werden soll.
Jede dieser Varianten steht für ein eigenes, meinungsgeprägtes Verfahren. Und für jede von ihnen gibt es Entwickler, die predigen, dass ihre Variante die einzig wahre ist. Ohne TDD ist es doch gar keine Softwareentwicklung, oder?
Meinungsgeprägte (Opinionated) Frameworks
Die Welt von Javascript ist voller Wunder. Es gibt Frameworks, die für das DOM-Rendering und die Kapselung von Modulen jeweils einen ganz anderen Ansatz nutzen. Eine Webanwendung (oder mobile Anwendung) kann auf tausend verschiedene Arten erstellt werden und jedes der genutzten Frameworks weist eigene "bewährte" Verfahren auf, die alle nicht zueinanderpassen.
Das Rendering auf Serverseite wurde erst kürzlich verbannt – um direkt wieder als das neue coole Ding zurückzukommen, als teilweises serverseitiges Rendering, um die Anwendung zu "beschleunigen". Derzeit lautet die Best Practice, Inhalte, die sich seltener ändern, auf Serverseite und Inhalte, die sich häufig ändern, im Browser zu rendern. Manche werden dem zustimmen, andere werden sagen, das sei verrückt.
TailwindCSS ist ein Beispiel für ein besonders meinungsgeprägtes CSS-Framework, in dem die Styles über die Klassen verwendet werden. Viele Menschen hassen diese Vorstellung und argumentieren, dass "HTML aufgeblasen wird, Tailwind wie eingebettete Styles funktioniert und die Trennung zwischen Style und Markup verletzt" . Die gängige Meinung besagt das genaue Gegenteil von Tailwind – ein Großteil des CSS soll in den Stylesheets verborgen werden, und für jedes Element soll eine einzelne Klasse zum Einsatz kommen. Mir hingegen gefällt das Konzept, und ich glaube, ich werde effizienter, wenn ich beispielsweise HTML-Änderungen für meinen Blog vornehme.
Wer hat also Recht? Niemand. Jeder hat seine eigene Meinung, und diese Meinungen sind alle berechtigt, auch wenn sie gegensätzlich sind.
Wenn ein Programm versucht zu erraten, was Nutzer wollen
Meinungsgeprägte Produkte
Beispielsweise versucht Microsoft Excel zu erraten, was wir beabsichtigen. Manchmal ist die Annahme aber falsch, so dass wir in die Konfiguration gehen und die Schriftart, die Art der Tabelle und ähnliches ändern müssen. Dabei kommt also Konvention vor Konfiguration. Das heißt, das Produkt funktioniert in 90 Prozent der Fälle hervorragend. Bei Bedarf können jedoch die anderen zehn Prozent geändert werden.
Es gibt jede Menge meinungsgeprägte Produkte – selbst, wenn wir nur Kalenderanwendungen betrachten. Es gibt so viele unterschiedliche Möglichkeiten, Kalender und Wochenpläne anzuzeigen, dass Hunderte Anwendungen mit ganz individuellen Einstellungen existieren. Beispielsweise ermöglichen manche Apps das Buchen von Slots nur in stundenweisen Blöcken, andere bieten Wochenansicht.
Ein hervorragendes Beispiel in der Java-Welt ist Ant vs. Maven. Mit diesen Entwicklertools lassen sich ausführbare Java-Dateien erstellen. Ant bietet eine enorme Flexibilität, bei der alles spezifiziert werden muss, während Maven die meisten Optionen ausblendet, aber die Möglichkeit bietet, die Standardeinstellungen zu überschreiben.
Maven erfreut sich im Java-Ökosystem deutlich größerer Beliebtheit als Ant, weil es in 90 Prozent der Fälle extrem anwenderfreundlich ist. Die restlichen zehn Prozent lassen sich in der Konfiguration ändern.
"Konventionen sorgen für ein meinungsstarkes Produkt. Meinungsstärke sorgt beim Benutzer für Begeisterung. Begeisterung beim Benutzer sorgt für erfolgreiche Unternehmen" , schreibt der Entwickler Adil Aijaz in Want a killer product? Become more opinionated(öffnet im neuen Fenster) .
Meinungsgeprägte Prozesse
Es gibt Menschen, die glauben, es sei falsch, nicht komplett agil zu handeln. Darf es überhaupt Softwareentwicklung heißen, wenn das Ganze nicht nach den Gesetzen der agilen Götter durchgeführt wird?
Auch das stimmt natürlich nicht. Es gibt so viele Meinungen zum Thema agile Entwicklung, dass das ursprüngliche Manifest überhaupt keinen Sinn mehr ergibt. So habe ich beispielsweise in den letzten Monaten mehrere, sich teils widersprechende Aussagen zur Umsetzung von Schätzungen und der Planung für agile Teams gehört.
1. Schätzungen müssen nach Story Points erfolgen.
2. Schätzungen müssen nach Stunden erfolgen.
3. Schätzungen sollten überhaupt nicht vorgenommen werden. Stattdessen ist die Story in möglichst kleine Aufgaben aufzuschlüsseln.
4. Agile Entwicklung ist Quatsch. Die Wasserfallmethode ist die beste.
Auch wenn viele aktuell die agile Entwicklung für das beste Verfahren halten, gibt es so viele verschiedene Meinungen zu deren Umsetzung, dass es nicht sinnvoll ist, blind irgendeinen Rat zu befolgen.
Es gibt einen einfachen Leitfaden für die Einführung beliebiger Methoden: Eine möglichst zu den Zielen passende Methode zu nutzen und so lange daran zu ziehen, drücken, quetschen, bis sie für die jeweilige Organisationsform passt – so lässt es sich möglichst effektiv arbeiten. Wenn irgendein Bestandteil der Methodik für Ineffizienz sorgt, darf er entfernt und durch eigene Regeln ersetzt werden.
Meinungsgeprägtes Fazit
Es gibt keinen Königsweg, der automatisch zu Effizienz führt. Ganz im Gegenteil sinkt die Effizienz sogar, wenn irgendeine Methodik mit dem Versuch genutzt wird, sie exakt der Beschreibung nach zu implementieren.
Agiles Arbeiten bedeutet nicht, dass es für alles eine Regel gibt und wir nur der rot gestrichelten Linie folgen müssen. Das einzige, was wirklich zählt, ist das Ergebnis. Und wenn es im Unternehmen eine einzigartige Variante der Scrum-Methodik gibt – kein Problem, solange diese Variante funktioniert.
Meinungen zählen. Der Kontext macht eine Situation eindeutig, und die gewählten Tools müssen an die Umstände angepasst werden.
Jedes gewählte Framework, jede gewählte Programmiersprache und jede gewählte IDE ist lediglich ein Tool, um auf effiziente Weise von Punkt A zu Punkt B zu gelangen, ohne die eigenen Werte zu beschädigen. Solange das zutrifft, herzlichen Glückwunsch. Das System funktioniert.
IMHO ist der Kommentar bei Golem.de. IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).
Vadim Kravcenko(öffnet im neuen Fenster) ist CTO der Firma Mindnow, die unter anderem Websites und mobile Apps entwickelt. Begonnen hat er als Entwickler unter anderem mit PHP und Javascript, mit der Programmierung von Custom-CMS, Plugins für Wordpress und Android- und iOs-Apps in Python.