Hinter den Kulissen
Wie entwickeln wir unsere Software?
von Oliver Herren
Routine und eingespielte Prozesse sind etwas Schönes. Doch Alltagstrott und Bequemlichkeit sind Feinde der Innovation. Wie wehrt man sich dagegen? Die Engineering-Teams von Digitec Galaxus kämpfen mit Manifesten gegen die Macht der Gewohnheit an. Das Beste: Die Erkenntnisse und Grundsätze helfen nicht nur beim Programmieren weiter. Teil 1: Schätze Variation!
Mal abgesehen von sanitären Einrichtungen, der Medizin, dem Schulwesen, Wein, der öffentlichen Ordnung, der Bewässerung, Strassen, der Wasseraufbereitung und der allgemeinen Krankenkassen: Was, frage ich euch, haben die Römer je für uns getan?
Das ist ein sehr plakatives Beispiel von Innovationsfeindlichkeit. Aber aufgepasst, es ist nicht immer so offensichtlich. Das zeigt das folgende Beispiel.
Der Biologe Gordon R. Stephenson führte Mitte des zwanzigsten Jahrhunderts ein erstaunliches Experiment durch: Er sperrte Rhesusaffen in einen Käfig in dessen Zentrum sich eine Banane befand. Jedes Mal wenn der Affe sich der Banane näherte schoss er mit einem schmerzhaften Luftstrahl auf das Tier. Die Äffchen begriffen schnell, dass es klug war, die Banane Banane sein zu lassen. Einige Zeit später schickte er einen weiteren Rhesusaffen ins Gehege. Natürlich erweckte die Banane sofort das Interesse des Neuankömmlings. Als er sich dem leckeren Objekt der Begierde näherte, geschah etwas Aussergewöhnliches: Der Zellengenosse, der vorher mit Druckluft malträtiert worden war, geriet in Panik. Mit vor Entsetzen aufgerissenen Augen drohte er dem anderen. Er solle sich bloss von der Frucht fernhalten! Das Tier, das die Bestrafung nie am eigenen Leib spüren musste, liess von seinem Vorhaben ab. Selbst nachdem der erste Affe entfernt worden war, wagte es der unbescholtene Rhesusaffe nicht, die Banane zu nehmen.
Wie den unfreiwilligen Helfern dieses Experiments, fällt es uns Menschen oft schwer, den Status Quo und die herrschenden Sitten zu hinterfragen. Wie schön wäre es, wenn wir die Banane ohne Vorurteile aufheben und verschlingen würden?
Wir wollen Änderungen nicht blind gutheissen, aber sie genau so wenig im Vorhinein verteufeln. Offenheit soll unser Handeln leiten. Wenn wir Schwierigkeiten haben, am Framework oder auch an Prozessen zu arbeiten, wollen wir das nicht einfach hinnehmen, sondern aktiv hinterfragen, ob die Prozesse und das Framework nicht verbessert werden können. Wir sollten uns bewusst sein, dass nichts in Stein gemeisselt ist. Es ist nicht nur erlaubt, sondern in hohem Masse erwünscht, dass man mitdenkt und Verbesserungsvorschläge einbringt, wo man Potenzial erkennt. Dafür haben wir etwa das Engineering-Board oder die Architekturgilde.
Lernen heisst Veränderung, Wissen ist Macht, und durch Lernen erlangen wir Wissen: Wir wollen lernen und wenn wir Kritik an unserem Code erhalten – niemand ist perfekt – dankbar sein für die Chance, ein noch besserer Entwickler zu werden. Code Reviews sollten uns daher nicht unangenehm sein. Andere Meinungen und Perspektiven können stets Mehrwert bringen.
Auch neue Tools können uns erheblichen Nutzen bringen, obwohl wir uns zunächst an sie gewöhnen müssen. Mir zum Beispiel war es ein unbeschreiblicher Moment, als ich erst kürzlich einen Git-Commit (es waren wirklich viele Änderungen), der verloren gegangen war, wiederherstellen konnte – mit SVN wäre dies ein Ding der Unmöglichkeit gewesen.
Könnte es sein, dass der eine oder andere diesen Text nicht kritisch genug gelesen hat? Wer mehr dazu erfahren möchte, sollte sich hier oder da weiter informieren. Und was stimmt nun? Es ist nicht einfach, in einer Informationsflut die korrekten Informationen zu finden. Oft wird die Qualität der Information vom Leser kaum berücksichtigt.
Fazit: Selber denken macht schlau!
Oder es überzeugt dich nicht, und du möchtest es weiterentwickeln? Wir haben folgende Stellenangebote in der Softwareentwicklung: