7 Dinge, die ich aus der Software Entwicklung fürs Leben gelernt habe

Es gab also Zeiten, in denen ich mich recht intensiv mit dem Entwickeln von Code befasst habe. Aber auch mit der Struktur des Codes und wie einzelne Code Komponenten schließlich ein zusammenhängendes System bilden. Ich habe mich in ganz unterschiedliche Softwareprojekte eingearbeitet und habe dabei auch verschiedene Herangehensweisen beobachtet. Vor allem Softwarearchitektur-Themen haben mich schnell begeistert, weil sie sich mit dem gesamten System befassen. 

 

Und ich stellte über die Zeit fest, dass vieles davon sich auf andere Bereiche übertragen lässt. Nämlich auf eben die Bereiche, in denen man versucht, ein System aufzubauen. Sei es ein Ordnungssystem im Haushalt, ein Finanzsystem für besseren Überblick. Oder ein System, um sich komplexen Themen anzunähern. Hier also meine Top sieben Learnings aus der Softwareentwicklung. 

1 Divide and Conquer

Zum Thema Komplexität und großer Aufwand stets ein guter Helfer: Teile & Herrsche. Das Problem in kleinere, überwindbare Probleme teilen. So versteht man komplexe Algorithmen – und wie man seine Wäscheberge bezwingt.

 

2 DRY – Don’t Repeat Yourself

Meistens, wenn man merkt man wiederholt sich, ist es Zeit für eine übergeordnete Funktion. Wenn wir feststellen, dass wir dieselbe Logik immer wieder implementieren, lohnt es sich, sie an einer zentralen Stelle zusammenzufassen. So vermeiden wir unnötige Wiederholungen und reduzieren Fehlerquellen. Im Leben ist Wiederholung allerdings nicht immer schlecht. Eine gute Routine ist schließlich auch eine Form von DRY: Wir müssen nicht jedes Mal neu entscheiden, wie wir etwas erledigen.

 

3 KISS – Keep it simple, stupid!

Das ist ebenfalls ein schönes Prinzip. Vor allem im Code, wo manchmal durch ein Wort sehr viel im Hintergrund geschieht, ist es wichtig, sich nicht gefährlich zu verzetteln: viele spätere Probleme werden sehr viel Zeit kosten, wenn Code oder Codestruktur so komplex aufgebaut werden, dass niemand es mehr versteht. Im wahren Leben kann man es sich manchmal sehr umständlich machen, oder zu viel auf einmal. Beides ist anstrengend und es hilft, die Dinge simpel zu halten wo möglich.

 

4 YAGNI – You ain’t gonna need it

Erst wenn etwas gebraucht wird, wird es auch gebaut. Manchmal ist man verleitet, schnell die zweite Funktion zu schreiben, die so ähnlich ist, aber erst später gebraucht wird. Manchmal stellt sich raus, wir dachten nur wir bräuchten es, aber unterwegs haben neue Erkenntnisse zu neuen Lösungne geführt, wir brauchten es doch nicht. Dann ist da ungenutzter Code, der eher stört. Wieviele Dinge besitzt man, nur weil man glaubt, man bräuchte es später noch mal? Oder bereitet sich auf ein unangenehmes Gespräch vor, welches gar nicht so unangenehm wird? 

 

5 Technische Schulden vermeiden

Technische Schulden entstehen bewusst oder unbewusst, wenn wir heute eine Lösung wählen, deren Konsequenzen uns später zusätzliche Arbeit verursachen. Manchmal passiert das aus Nachlässigkeit, manchmal ganz bewusst, um schnell voranzukommen. Problematisch wird es, wenn wir vergessen, dass wir diese Schuld aufgenommen haben. Alles, was beim Einrichten nicht berücksichtigt wird, fliegt einem zu einem späteren Zeitpunkt um die Ohren. Und das ist im Betrieb meist viel schmerzhafter als in der Entwicklung. Wehret den Anfängen, sagt man auch im Volksmund. Oder Gewinner erkennt man am Start, Verlierer auch. Man darf es nicht übertreiben mit der Vorsicht, jedoch ist gut Planung und ein Vorgehen mit Bedacht vor allem bei Lösungen und Entscheidungen wichtig, die uns lange dienen sollen. 

 

6 Systeme modular statt monolithisch

Software wurde und wird häufig zunächst als zusammenhängendes System entwickelt: Ein Programm wächst, bekommt neue Funktionen und wird mit der Zeit immer größer und komplexer. Irgendwann können Wartung und Veränderung schwierig werden, weil Abhängigkeiten unüberschaubar werden.

Eine Antwort darauf ist, Systeme stärker zu modularisieren: Funktionen und Verantwortlichkeiten werden voneinander getrennt und so gestaltet, dass einzelne Teile unabhängig voneinander verstanden, verändert oder ausgetauscht werden können. Später kamen dafür unter anderem Architekturen wie Microservices und technische Ansätze wie Containerisierung hinzu.

Auch wir können Dinge modular betrachten und angehen: Alltägliche Aufgaben so gestalten, dass sie in kleinen Blöcken zu erledigen sind. Ein Projekt nicht als eine große Sache begreifen, sondern einzelne Module nacheinander oder parallel entwickeln.

 

7 früh testen

Testen und auch Dokumentation sind in der Softwareentwicklung eher die lästigen Themen, die meistens nicht so gern ausführlich besprochen werden, oder nicht gern gemacht werden. Teilweise ist das begründet, es ist wohl wie mit Versicherungen: man kann es auch übertreiben. Aber wenn wichtige Funktionen nicht getestet werden, entstehen vermeidbare Fehler. Wer sich einmal auf eine Strategie eingestellt hat und den Moment verpasst hat, an dem diese keinen Sinn mehr machte, der weiß wovon ich spreche. Auch wenn wir etwas entwickeln, aber uns kein Feedback einholen, ist das wie ungetestete Software: Wir wissen nicht, wie es im Kontakt zur Außenwelt überhaupt wirkt und die Gefahr ist groß, dass wir etwas Wichtiges übersehen. Am fertig entwickelten Ergebnis nochmal was nachzubessern, ist schwieriger, als es in der Entwicklung gleich richtig zu machen. Wir müssen nicht alles vorher wissen. Wir können ausprobieren, Feedback bekommen und unseren Kurs anpassen.

 

Das waren sie also, meine sieben Learnings aus meiner Zeit in der Softwareentwicklung. Ich hoffe, sie helfen dir dabei, an manche deiner Themen wie an die Entwicklung eines Systems heran zu gehen. Such dir einen Themenbereich, mit dem du immer wieder zu tun hast (Lebensmittel einkaufen, Rechnungen schreiben, ein Buch schreiben etc.) und entwickle diese Tätigkeit wie ein System. Wende dabei die Prinzipien an und wenn du möchtest, schreib mir gern, auf welche Erkenntnisse du dabei gestoßen bist.