Ein halbes Jahrhundert der Software-Entwicklung ist von einem überraschenden Phänomen geprägt: Wir, die Entwickler:innen + Architekt:innen, haben nicht nur immer wieder neue Technologien und Architekturansätze geschaffen, sondern auch Methoden entwickelt, die über die reine Programmierung hinausgehen. Projektleiter, Anwender, Betrieb und Tester haben von unseren Innovationen profitiert. Dieser Vortrag berichtet über die erstaunlichen Beiträge, die unsere Disziplin konzipiert und entwickelt hat, und wagt einen Blick in die Zukunft unserer Disziplin.

Zielpublikum: Alle
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Nach diesem Vortrag werden die Teilnehmenden voller Motivation ihre Reise durch die OOP antreten.

Neben dem Blick in die Vergangenheit wird die Zukunft unserer Disziplin den Schwerpunkt dieses Vortrags bilden.

Unter „Resilienz“ versteht man die Fähigkeit von Systemen, auch unter massiven Störungen von außen ihre Funktionsfähigkeit zu erhalten. Die Coronakrise mit ihren massiven Einschnitten und Opfern hat uns vor Augen geführt, dass Resilienz von Unternehmen entscheidend sein kann für das weitere Überleben. In diesem Vortrag betrachten wir Situationen, in denen Resilienz von besonderer Bedeutung ist, und leiten daraus ab, welche Voraussetzungen Unternehmen erfüllen müssen, um Resilienz zu zeigen. Spoiler: Auch Agilität spielt dabei eine Rolle ...

Zielpublikum: Manager:innen, Entscheider:innen, Organisations-Entwickler:innen, Coaches
Voraussetzungen: Verständnis über Unternehmenssteuerung und Agilität
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Roter Faden dieses Talks ist eine Analogie zwischen der Situation, in der sich Unternehmen während der Coronakrise befanden und noch immer befinden, und den (frei interpretierten) Phasen der Behandlung lebensbedrohlicher medizinischer Notfälle, für die sich in den letzten 50 Jahren weltweite Standards etabliert haben (nein, es wird keine Schockfotos geben. Mir geht es um Taktik und Strategie, nicht um Sensationslust).

Für jede der Phasen (unmittelbare Existenzsicherung, Ursachenfindung, Aufbau von Handlungsoptionen, Ausprobieren der Optionen, Einrichten auf die neue Normalität) wird analysiert, welche Eigenschaften und Praktiken Unternehmen dabei unterstützen oder behindern und wie man sie fördern kann. Dass dabei viele Ähnlichkeiten mit agilen Ansätzen aufscheinen, ist nicht überraschend, wichtig sind aber auch die Bereiche, in denen Agilität alleine nicht ausreicht.

Was hat das mit Tintenfischen zu tun? Diese kommen aus einer Analogie der "Supporting Agile Adoption"-Arbeitsgruppe der Agile Alliance, in der Oktopusse als Beispiel für einen völlig anders organisierten Organismus dienen, der dezentral mit neun Gehirnen kognitive Leistungen erbringt, die sich mit intelligenten Säugetieren messen lassen können. Es zeigt sich, dass die Fähigkeit von Organisationen, Entscheidungen verteilt fällen zu können, ihre Resilienz wesentlich verbessern kann.

Haben Sie schon einmal gesagt bekommen: Arbeite Dich mal in dieses Projekt ein - wir sollen es übernehmen?

Haben Sie dann Unmengen von Doku bekommen (aber nicht Unmengen von Zeit), um in ein paar Tagen ein Statement dazu abzugeben?

Die ganze Informatik-Ausbildung ist darauf ausgerichtet, Software zu schreiben.

In der Praxis angelangt, stellt man aber schnell fest, dass dies weniger als "die halbe Miete" ist.

Warum? Weil Entwickler:innen viel mehr Zeit damit verbringen, Software bzw. deren Dokumentation zu lesen, als neue zu schreiben.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Haben Sie schon einmal gesagt bekommen: Arbeite Dich mal in dieses Projekt ein - wir sollen es übernehmen?

Haben Sie dann Unmengen von Doku bekommen (aber nicht Unmengen von Zeit), um in ein paar Tagen ein Statement dazu abzugeben?

Die ganze Informatik-Ausbildung ist darauf ausgerichtet, Software zu schreiben.

In der Praxis angelangt, stellt man aber schnell fest, dass dies weniger als "die halbe Miete" ist.

Warum? Weil Entwickler:innen viel mehr Zeit damit verbringen, Software bzw. deren Dokumentation zu lesen, als neue zu schreiben.

Dieser Talk zeigt Tipps und Best Practices, wie man effizient Dokumentation und Code lesen und erfassen kann.

Dabei liefert er auch einen Einblick in das, was dort nicht steht, bzw. Tipps, wie man genau diese Lücken füllen kann.

Er gibt Tipps zum schnellen Erfassen des Inhaltes bzw. zur zielgerichteten Analyse. Aus der Praxis - für die Praxis!

Lernen Sie die "Kunst des Unperfekten" kennen!

Die aktuellen "Best Practices" in der Software-Entwicklung, von TDD, Domain-Driven Design, Continous-Delivery, agiles Vorgehen usw., haben eine Gemeinsamkeit: Ihre Erfolgsversprechen basieren vor allem auf Anekdoten in Blogposts, Konferenzvorträgen und anderen Veröffentlichung von den Digitalchampions Google, Amazon, Facebook und anderen "Koryphäen". Warum ist das eigentlich so? Kann es auch anders sein? Diese und viele andere Fragen werden in diesem Vortrag diskutiert.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die aktuellen "Best Practices" in der Software-Entwicklung, von TDD, Domain-Driven Design, Continous-Delivery, agiles Vorgehen usw., haben eine Gemeinsamkeit: Ihre Erfolgsversprechen basieren vor allem auf Anekdoten: Blogposts, Konferenzvorträgen und andere Veröffentlichung von den Digitalchampions Google, Amazon, Facebook sowie den "Koryphäen" unseres Faches erzählen davon, wie sie verschiedene Probleme bei der Software-Entwicklung gelöst haben. Jedoch handelt es sich meistens um Einzelfälle in ganz spezifischen Kontexten. Und die Problemlösungen ändern sich rasend schnell. Systematische Untersuchungen, welches Vorgehen bei welchem Problem das richtige ist, haben dagegen Seltenheitswert. Arbeiten aus der akademischen Welt sind oft praxisfern. Bestenfalls münden sie in exotischen Programmiersprachen, deren Ideen vielleicht irgendwann mal in der Praxis landen. Warum ist das eigentlich so? Kann es auch anders sein? Diese und viele andere Fragen werden in diesem Vortrag diskutiert.

My hope for the future of software development; We learn that we are responsible for so many big and small impacts to society and that we have to take that seriously. We learn that even if software processes are described in great detail, we should not stop questioning whether we are still doing the right thing, the right way. We can bring our whole self to work. But most of all we learn that continuous integration is something you must have, continuous delivery is very nice to have, and continuous deployment is but a lovely dream for most.

Target Audience: Software developers, agile coaches, managers, leaders, and anyone married to a software developer
Prerequisites: Experiences in agile software development
Level: Basic

Extended Abstract:
I have been in software development for 22 years, and I have seen trends come and go like the fascinations of a teenager. I have taught RUP and years later, I have laughed at RUP. On the other hand, I have laughed at Artificial Intelligence, but some years later, AI laughed at me.

This talk will describe how I think the future of software development will look if we reflect now and learn from the past. Learn to bring your whole self to work, and accept that others do the same. Learn that even if software processes can be described in great detail you should not stop questioning whether you are still doing the right thing in the right way. Learn that we are responsible for so many big and small impacts to society and that we have to take that seriously. But most of all learn that continuous integration is something you must have, continuous delivery is very nice to have, and continuous deployment is a lovely dream for most people.

In summary, I will borrow words from Dr Emmett Brown: “Roads? Where We’re Going, We Don’t Need Roads.” Developers will fly over the roadmaps and stage-gate systems and do exactly, no more, no less, what is needed to build wonderful software systems and to stay sane and human in our field.