Tags

, , , , , ,

Das Tolle an einer abwechslungsreichen Arbeit ist, dass man verdammt viel daraus lernen kann. Da rattert soviel durch, dass ich manchmal den Drang spüre das ganze ein wenig zu strukturieren. Und das hier ist eines der Themen.

Praktikanten und Berufsanfänger in der Softwareentwicklung machen immer wieder ähnliche Fehler. Fehler an die ich mich auch aus meiner Anfangszeit noch dunkel erinnere. Zumindest weiß ich noch, wie ich das ein oder andere Aha-Erlebnis hatte. (Und zum Glück habe ich immer noch ständig welche :-)

Beim Strukturieren der Fehler wird schnell klar, dass der Aha-Moment in jedem Fall eine Art „Abstand nehmen“ ist. Jedes Mal geht man einen Schritt zurück und guckt sich das Ganze etwas globaler an. Und dann merkt man, dass man selber – oder die eigene Annahme – doch nicht der Mittelpunkt der Welt ist. 

Ein Beispiel:  Ein Praktikant sollte in einer Webanwendung das Hochladen von Dateien realisieren. Der Betreffende hatte das sehr schön umgesetzt und war sich sicher fertig zu sein. Alle Dateien, die hochgeladen wurden, landeten auf dem Server im gleichen Ordner. Das klappte alles wunderbar – solange die Dateien nicht den gleichen Namen hatten. Die Erkenntnis, dass sie sich dann überschrieben, sorgte für ein kleines Aha-Erlebnis.

Natürlich kann man sagen, dass man da doch von alleine drauf kommen kann und ich bin mir sicher, dass dieser sehr fähige Entwickler das auch noch von selber gemerkt hätte. Aber irgendwann muss sich dieser Aha-Erlebnis einmal eingestellt haben, egal ob man selber darauf kommt oder jemand anderes.

Interessant finde ich an dem Beispiel, dass es hier um das Zurücktreten aus dem Mittelpunkt geht. Abstand gewinnen um eine globalere Perspektive zu bekommen. In diesem Fall geht es ganz trivial darum, dass mehrere Dateien den gleichen Namen haben können. Aber in der folgenden Aufzählung von typischen Fehlern – oder Fehlkonzepten wenn man so will – wird klarer worum es geht. Man muss immer wieder andere Benutzer, andere Perspektiven und auch andere Zeiten berücksichtigen. In jedem der Fälle muss man sich vom „Hier und Jetzt“ lösen, Abstand gewinnen und einen höheren Gesamtzusammenhang betrachten.

Abstand nehmen vom eigenen Gefühl

Darunter fallen Annahmen, die ich auf mein Programm projiziere und deshalb nicht mehr prüfe. Ich bin mir ganz sicher, dass in meinem Teil des Programms kein Fehler ist und muss es deshalb auch nicht prüfen. Und so sucht man dann ewig in anderen Programm-Teilen und findet die Ursache nicht.

Wenn man das einmal erlebt und gelernt hat, prüft man im Fehlerfall lieber gleich jeden Teil des Programms. (Am Besten gleich mit Unit Tests :-)

Abstand nehmen vom ICH – verschränkte Daten

Ähnlich wie im Beispiel oben mit den Dateien lernt man irgendwann, dass bei einer Webanwendung nicht nur ein Benutzer das ganze bedient sondern viele darauf zugreifen. Solange man als Entwickler die Webseite alleine programmiert und alleine testet, merkt man gewisse Seiteneffekte gar nicht, die erst auftreten wenn mehrere Benutzer darauf zugreifen.

Wenn man einmal erlebt hat, wie mysteriös und unberechenbar eine Anwendung wird, weil die gleichen Daten von verschiedenen Benutzern gleichzeitig verändert werden, dann überlegt man zukünftig wirklich zweimal, wie man die Architektur seines Programms gestaltet.

Das ganze darf man dann nochmal erleben, wenn man noch mehrere Server betreibt, die auf den gleichen Daten arbeiten (Stichwort Clustering). Hier kann es ganz ähnliche mühselige Effekte geben.

Abstand nehmen vom ICH – mehr Teilnehmer im Projekt

Was beim Abstand vom „Ich“ auf einer anderen Ebene noch auftaucht sind die anderen Teilnehmer im Projekt. Viele Probleme in Projekten werde immer wieder durch den Tunnelblick (nicht nur der Entwickler :-) verursacht. Der Tunnel hat auch sein Gutes, aber ab und zu lohnt es sich auch mal den Blick zu heben, ein wenig  Abstand von sich selbst zu nehmen und zu sehen, was will eigentlich der Kunde, was will der Chef, was braucht der Support, was brauchen meine Kollegen? Was sind deren Perspektiven?

Ein kluger Mann hat mir mal gesagt er würde sich immer fragen: was braucht mein Chef als nächstes. Wenn man sich auf die Perspektive einlässt, dann geht man beispielsweise an das Erstellen einer Präsentation ganz anders heran. Anstatt einfach nur die technischen Fakten meines Projekts aufzuzählen, die mir am schnellsten in den Sinn kommen, überlege ich mir erstmal was will mein Chef mit der Präsentation und warum will er sie überhaupt. Er will den Kunden überzeugen. Also frag ich mich, was überzeugt den Kunden? Was will der Kunde? Warum könnte er unsere Software haben wollen? Er möchte effektiver Arbeiten können mit unserer Software. Und schon stelle ich ganz andere Punkte in der Präsentation zusammen.

Wenn man einmal erlebt hat, wie einen der eigene Chef oder Kunde einen nicht versteht, dann sei dir sicher: Das wird immer wieder passieren :-)

Die Suche nach dem „Wer“ und dem „Warum“ hat mir aber ein Stück geholfen. Sehr zu empfehlen in diesem Zusammenhang ist der Vortrag zum „Why“ von Simon Sinek:

Abstand nehmen von der eigenen Kompetenz – Teamarbeit

Immer wieder glaubt man, ein Problem doch ganz alleine Lösen zu können. Passiert mir auch ständig und dann merkt man, dass andere doch nochmal einen besseren Blick auf das Problem haben.

Wenn man einmal erlebt hat, wie man Stunden oder Tage in eine Aufgabe versenkt hat und sich dann ein Kollege das Programm ansieht und in ein paar Minuten eine Lösung findet, der lernt die Kompetenz der anderen zu schätzen.

Das spielt in der Softwareentwicklung auch oft auf Ebene der ganzen Firma eine Rolle: Immer wieder mal möchte man ein komplexes Feature in ein Projekt reinbauen unter massivem Zeitbedarf. Und dann kommt einer und sagt: Warum nimmst du nicht den Shop und bindest den an?  „Make or Buy“ :-) Aber da liegt der Fehler wohl im Denk-System: Ständig denkt man darüber nach, wie man etwas entwickeln kann, da fällt der Sprung raus aus der Entwickler-Denke manchmal nicht ganz einfach.

Abstand nehmen von der eigenen Kompetenz – die ersten 80%

Zu Beginn eines Softwareprojekts kommt man immer schnell voran. Und wenn man 80% erledigt hat, verfällt man schnell in die Einschätzung, dass man bald fertig ist. Auch Kunden denken gerne so, wenn sie einen Prototyp sehen. Da empfiehlt es sich das Paretoprinzip im Kopf zu behalten.

Wenn man einmal gegenüber dem Chef oder Kunden seine Zeitschätzung ständig verlängern musste, dann überlegt man sich das beim nächsten Projekt nochmal.

Abstand nehmen vom Augenblick – Zeitkritisches? 

Was mache ich Zuerst und was kann ich später machen. Das sind Fragen die man sich ruhig täglich stellen kann. Wenn ich beispielsweise weiß, dass die IT immer 2 Tage braucht um den Server aufzusetzen, dann sollte ich das nicht erst beantragen, wenn ich mit der Aufgabe anfangen möchte.

Wenn man einmal erlebt hat, dass der Kunde schon im frühen Wochenende ist, wenn man die alles entscheidende Frage stellt, fragt beim nächsten Mal schon morgens…

Abstand nehmen vom Augenblick – mein zukünftiges Ich

Immer wieder gern vergisst man auch sein eigenes zukünftiges Ich. Ob ich in einem Monat noch weiß, was ich heute getan habe oder verstanden habe? Ein bisschen Doku hat noch keinem geschadet…

Wenn man einmal vergeblich versucht hat seine eigene Regular Expression nachzuvollziehen, die man vor 3 Monaten zusammengezimmert hat, der weiß wovon ich rede…

Abstand nehmen von der gefühlten Zuständigkeit – kenn ich nicht

Gerne zieht man sich als Entwickler auf seinen Programmcode zurück. „Da kenne ich mich nicht aus.“, „Das ist nicht von mir.“, „Das ist ein Frontend-Problem, ich bin Backend-Entwickler“, „Das hat ein anderer gemacht.“  Ja ok, dann red ich mit dem anderen oder gucks mir wohl oder übel doch selber an.

Wenn man mal erlebt hat, dass man selbst gesagt hat „Das ist ein Frontendpoblem“ und dann war es doch ein Problem im eigenen Backend, dann guckt man beim nächsten Mal doch lieber zusammen drauf.

Abstand nehmen von der eigenen Sicherheit – geschwind ein Update

Immer wieder gern gemacht: Schnell noch ein Update vor dem Livegang, vor dem Feierabend, vor der Präsentation. Ehrlich Leute: Machts einfach nicht, egal wie sicher ihr euch seid. Murphy ist immer bei euch!

Wer schon mal ein Wochenende lang damit kämpfen konnte, das letzte Update von Freitag Abend wieder rückgängig zu machen, der überlegt sich das nächste Mal ob er auf den Knopf klickt  (wenn es nur nicht immer so verführerisch wäre :-)