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.
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 10 Jahren als Javaentwickler 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.
