Rallye-Meisterschaften stellen die Fahrzeuge, ihre Fahrer und die Konstrukteure vor ganz besondere Herausforderungen. Im Gegensatz zu Rundrennen wird hier nicht auf speziell konstruierten Strecken, sondern auf abgesperrten Straßen- und Schotterabschnitten bei Wind und Wetter gegen die Uhr gefahren. Dabei reicht die Variation von waldigen Strecken in Finnland bis zum afrikanischen Kontinent. Um diesen stark unterschiedlichen Ansprüchen zu genügen und die Fahrzeuge derartig anpassbar zu gestalten, muss vor allem eins gegeben sein: Simplizität.
Ich möchte bei meinem Vortrag Parallelen zwischen der Softwareentwicklung und dem Rallyefahren herausarbeiten und versuchen, Prinzipien aus dem Sport auf unsere Tätigkeit als Entwickler anzuwenden.
Wie schafft man es beispielsweise seine Software so zu konstruieren, dass man am Straßenrand das Differential auswechseln kann? Wieviel Schrauben muss man am Kotflügel lösen, um mitten im Sprint eine größere Anpassung an der Architektur vorzunehmen?
Dabei soll auch nicht davor zurückgeschreckt werden, mit alteingesessenen Mustern und Grundsätzen zu brechen, um herauszufinden, ob sie wirklich so universell sind, wie es viele glauben. Denn: ohne radikal zu denken, schafft man es nicht, von 0 auf 100 in unter 2,6 Sekunden auf Schotter zu beschleunigen.
Rallye-Meisterschaften finden unter kontrolliert unkontrollierten Bedingungen statt: auf unebenen und unbefestigten Straßen, bei jedem Wetter, auf jedem Kontinent. Wie schafft man es, da noch ein Rennen zu fahren? Teamwork und Simplizität sind die wichtigsten Faktoren. Ich möchte bei meinem Vortrag Parallelen zwischen der Softwareentwicklung und dem Rallyefahren herausarbeiten.
Alles hat seine Kosten, wie können wir herausfinden, ob sie es wert sind? Wie erkennen wir unnötigen Ballast, der uns hindert, schnell zu iterieren und Lösungen zu finden?
Wenn in der finnischen Einöde ein Fahrerteam im Rennbetrieb einen Reifen wechseln kann, können gut aufgestellte Teams mitten im Sprint genauso die Architektur auf plötzlich geänderte Anforderungen anpassen. Um das zu erreichen, soll auch nicht davor zurückgeschreckt werden, alteingesessene Muster genauer unter die Lupe zu nehmen und neu zu bewerten. Denn: mit Heckantrieb allein schaft man es nicht, auf Schotter von 0 auf 100 in unter 2,6 Sekunden zu beschleunigen. Dafür braucht man Quattro.
Rallye-Meisterschaften finden unter kontrolliert unkontrollierten Bedingungen statt: auf unebenen Straßen, bei jedem Wetter. Teamwork und Simplizität sind da die wichtigsten Faktoren. Ich möchte Parallelen zwischen der Softwareentwicklung und dem Rallyefahren herausarbeiten.
Alles hat seine Kosten, wie können wir herausfinden, ob sie es wert sind? Wie erkennen wir Ballast, der uns hindert, schnell zu iterieren?
Gute Teams können mitten im Sprint die Architektur auf geänderte Anforderungen anpassen. Um das zu erreichen, soll auch nicht davor zurückgeschreckt werden, alteingesessene Muster genauer unter die Lupe zu nehmen und neu zu bewerten. Mit Heckantrieb allein schaft man es nicht, auf Schotter von 0 auf 100 in 2,6 Sekunden zu beschleunigen. Dafür braucht man Quattro.
Bei Rallyes wird nicht auf Rennstrecken, sondern auf abgesperrten Straßen bei Wind und Wetter gefahren. Um diesen Strapazen zu widerstehen muss vor allem eins gegeben sein: Simplizität. Ich möchte unsere Softwareentwicklung fit für den Wahnsinn des Alltags machen und versuchen, Prinzipien aus dem Sport auf unsere Tätigkeit als Entwickler anzuwenden. Wie schafft man es seine Software so zu konstruieren, dass man am Straßenrand das Differential auswechseln kann? Wieviel Schrauben muss man lösen, um die Architektur zu verändern? Dabei soll auch nicht davor zurückgeschreckt werden, mit bekannten Mustern und Grundsätzen zu brechen, um herauszufinden, ob sie wirklich so universell sind. Denn: ohne radikal zu denken, schafft man es nicht, in unter 2,6 Sekunden auf Schotter auf 100 zu sprinten.
Aus Goslar stammend und mit Braunschweig als Wahlheimat arbeite ich seit mehr als 15 Jahren als Softwareentwickler in allen Bereichen, die Software zu bieten hat. Dabei interessiert mich am Meisten die Meta-Seite der Entwicklung: wie baut man Code, der noch in der fernen Zukunft flexibel und wartbar ist? Wie kann man zusammen an Software arbeiten, ohne sich gegenseitig auf die Füße zu treten? Dabei beschäftige ich mich nicht nur mit Java allein, sondern habe im Bereich Cluster-Computing Kotlin zu schätzen gelernt und beim privaten Programmieren Clojure entdeckt und mich dabei Hals über Kopf darin verliebt.
- Lindbergh war der Meinung, dass beim Ausfall eines Motors eines voll beladenen mehrmotorigen Flugzeugs die verbleibenden Motoren die Maschine auch nicht in der Luft halten könnten. Das Risiko eines Motorenausfalls steige aber mit der Zahl der Motoren.
- Im Fiat 131 Homologationsmodell wurden an der Vorderachse untaugliche, da zu schwache, Bremsen verbaut. Für den Motorsport war dies egal, am Rennmodell wurden Motorsportteile verwendet.
Software, like religion, has almost no constraints so almost everybody's opinion is valid. Unlike engineering where if your opinion is wrong the roof falls down on your head, as a reminder.
