Podcast: Große Software-Projekte – Herausforderungen & Lösungen

Letzte Änderung: Jänner 2020

Viele unserer Software-Projekte sind groß, komplex und langlebig. Da kann ganz schön herausfordernd sein – welche Lösungen wir in der Umsetzung entwickelt haben, erzählen wir in einem Podcast!

Kein Kunde ist wie der andere – jeder hat seine individuellen Anforderungen und Rahmenbedingungen. Daher brauchen unsere Kunden Software, die auf sie zugeschnitten ist.

Offen gesagt, ist es gar nicht so einfach, eine Software nach Maß mit all ihren speziellen Anforderungen, Schnittstellen etc. in einem Team umzusetzen. Wie unsere Software-Entwicklerinnen und -Entwickler diese Herausforderung meistern, welche Prozesse und Modelle sie dafür entwickelt haben, erfahren Sie in diesem Podcast! Mit dabei sind Themen wie zum Beispiel Continuous Integration und Continuous Delivery, Fremdcode und Clean Architecture – sowie Sven Schweiger, Nicolas Köcher, Tobias Watzek und Isabel Birnstingl!

Transkript des Podcasts (gekürzte Fassung)

Isabel:
Herzlich willkommen beim Podcast des Software-Teams der CSS in Wien. In der heutigen Ausgabe wollen wir über die Herausforderungen sprechen, die wir als Software-Entwicklerinnen und -Entwickler meistern müssen, wenn wir sehr spezielle und individuelle Software-Projekte für unsere Kunden umsetzen. Für dieses Thema habe ich mir drei Experten und Kollegen dazu geholt. Das wäre zum einen Sven Schweiger – er ist einer unserer Geschäftsführer und auch Gründer. Das war vor 25 Jahren, nicht wahr, Sven?

Sven:
Genau, vor 25 Jahren.

Isabel:
Neben Sven sitzen auch noch im Raum Tobias Watzek und Nicolas Köcher. Beide sind Sofware-Entwickler hier in der CSS, jeweils in einem Software-Team. Gehen wir doch gleich mal in medias res: Sven, ich habe gerade erwähnt, wir haben spezielle Herausforderungen, wenn es darum geht, Software-Projekte für unsere Kunden umzusetzen. Was sind solche Herausforderungen?

Sven:
Heute reden wir mit dem Fokus Individualsoftware. In dem Bereich stellen wir Lösungen auf die grüne Wiese, so dass sie die Anforderungen unserer Kunden optimal erfüllen. Da haben ganz spezielle Herausforderungen.
Ich würde sagen, dass wir sehr viel mit komplexer Software zu tun haben. Das heißt, dass man, neben der Technologie die Problem-Domäne des Kunden verstehen muss. Also, auf Deutsch gesagt: Die Geschäftsprozesse und was man für Funktionalität braucht.

Dann soll die Software langlebig sein. Langlebig, weil wir hauptsächlich Anwendungen bauen, die viele, viele Jahre laufen müssen. Das heißt, man muss etwas so konstruieren, dass es in einigen Jahren auch noch updatefähig ist.

Dann gibt’s noch, dass unsere Kunden gerne auf Effizienz schauen. Sie verlangen ein gutes Preis-Leistungs-Verhältnis von uns. Wir sind in Österreich und da kostet halt die Arbeitsstunde Geld. Da muss man mit den Stunden gut haushalten. Das heißt, wie können wir effizient entwickeln und trotzdem mit modernen Technologien arbeiten und uns Zeit dafür nehmen.

Letztendlich gibt’s dann noch das Thema Teamarbeit an großen Projekten. Und natürlich auch regelmäßige Demos. Wir sind agil unterwegs, immer schon gewesen. Das bedeutet, dass unsere Kunden auch gewohnt sind von uns regelmäßig zu sehen, wie es ihrer Software-Entwicklung geht. Das ist aber durchaus eine Herausforderung, wenn man dann zu regelmäßigen Zeitpunkten herzeigbare Dinge haben muss, die dann auch funktionieren.

Das sind so einige Punkte die mir einfallen, wenn wir über komplexe Individualsoftware reden und wie man sie modern entwickelt.

Isabel:
Also, doch einiges an Dingen, die wir beachten müssen bei der Software-Entwicklung. Ich glaube, da können unsere zwei Softwareentwickler noch ein bisserl mehr dazu sagen. Wenn wir vielleicht zum Anfang springen. Du hast das Thema Komplexität erwähnt – es sind also oft recht komplizierte Software-Projekte, die wir umsetzen. Wie schaffen wir es in der Umsetzung, dem gerecht zu werden?

Tobias:
Es ist bei uns so: Wir haben nicht die kleine Website für den Friseur-Betrieb, sondern recht komplexe Domänen. Also Geschäftsprozesse, die wir mit unserer Software abbilden wollen. Dafür müssen wir uns als Software-Entwickler natürlich auch in das Ganze hineinfinden. Wir programmieren nicht nur blind herunter was an Requirements daherkommt. Wir versuchen zu verstehen, was steckt dahinter und eine gemeinsame Sprache zu definieren, so dass nicht der eine über Fenster redet und etwas ganz Anderes meint als der Software-Entwickler. Weil ein Software-Entwickler versteht unter „Fenster“ vielleicht am Bildschirm irgendwelche Sachen, die aufgehen, aber vielleicht geht es gerade um einen Betrieb der Fenster herstellt und man nennt Dingen dann Fenster und…

Isabel:
Ich wollte gerade sagen – ich habe nämlich, als du jetzt „Fenster“ gesagt hast, sofort an die normalen Fenster im Gebäude gedacht!

Tobias:
Genau, man muss eben eine gemeinsame Basis finden. Und das ist eben mal der Anfang. Wir versuchen uns von Experten erklären zu lassen, worum geht es wirklich.

Sven:
Also, du meinst Experten des Kunden. Wir nennen die ganz gerne „Champions“, also Leute, die in dem Betrieb wissen, wie die Dinge laufen.

Tobias:
Ja, genau die sind gemeint, die uns oder eben dem Product Owner die Geschäftsprozesse erklären. Das Modell ist im Endeffekt eine Darstellung des Ganzen, wo alles enthalten ist, was da sein muss.

Isabel:
Also, was ich einmal gesehen habe – das ist ja wie ein Diagramm sozusagen, nicht wahr?

Tobias:
Genau, man kann Diagramme dafür verwenden. Man kann das Ganze auch einfach nur schreiben aber Diagramme helfen natürlich – Klassen-Diagramme, UML kann man dafür verwenden oder EAD-Diagramme. So das man sich klar wird, was sind die Entitäten, also zum Beispiel ein Fenster als Entität, und was sind Aktionen, die damit passieren können, was gehört zu einem Fenster (ein Griff oder sonstiges).

Isabel:
Die Komplexität sozusagen übersichtlich machen?

Tobias:
Genau.

Sven:
Es ist übrigens sehr schön zu hören, dass einer unserer Software-Entwickler sagt: „Wir beginnen mit einem Modell und wir modellieren die Domäne des Kunden.“, und nicht: „Ich schreib mal eine Zeile Code und dann schau ma mal.“. Das unterscheidet sich sehr stark von dem Programmieren, von dem jeder glaubt, wie es ist. Wir haben ganz viele andere Dinge zu tun, vorher und auch parallel zum reinen Codieren.

Tobias:
Es sind komplexe Systeme und wenn wir jetzt gleich zum Programmieren starten würden, würden wir höchstwahrscheinlich in der Mitte des Projekts – oder schon viel früher – draufkommen, dass die Welt ganz anders ausschaut, als wir es uns gedacht haben. Es ist besser am Anfang mit etwas zu arbeiten, was man leichter verwerfen kann, als wenn man schon das halbe Programm geschrieben hat und dann draufkommt, eigentlich ist was ganz Anderes gemeint gewesen.

Isabel:
Wir haben das jetzt eher theoretisch beschrieben. Haben wir vielleicht ein Praxis-Beispiel? Eines unserer Projekte vielleicht, das man kurz beschreiben darf bzw. kann?

Nicolas:
Ja, das aktuelle Projekt AUTOSCAN, unser Produkt. Dort geht es bei der Domäne um Lager, Artikel oder um Scans. Beim Modell geht es unter anderem um die Abhängigkeiten zwischen eben diesen Artikeln, zwischen den Lagern in denen diese Artikel liegen. Und wir verwenden zum Beispiel hier auch die Sprache UML, um ein Diagramm dieser Entitäten, der Akteure und auch der Boundaries abzubilden. Boundaries sind bei uns die Grenzen bis wohin wir unsere Software entwickeln und wo dann entweder ein anderes Kundensystem anfängt oder wir aufhören zu programmieren. Das kann zum Beispiel auch ein User Interface sein.

Isabel:
Vielleicht nur kurz zur Erklärung: AUTOSCAN ist eine Barcodescanner-Lösung für die Lagerhaltung. Deshalb Lagerorte, Artikel und so weiter.

Nächstes Thema: Sven hatte als nächste Herausforderung noch die Langlebigkeit von Software erwähnt. Sven, weißt du wie lange die langlebigste Software gelaufen ist, die wir gemacht haben?

Sven:
Gute Frage. Ich würde mal sagen, über 10 Jahre auf jeden Fall.

Isabel:
Wenn wir jetzt ein Software-Projekt ganz neu machen – es, wie du immer sagst Sven, auf die grüne Wiese setzen – welche Möglichkeiten oder Lösungen haben wir, um dafür zu sorgen, dass es wirklich langlebig ist?

Nicolas:
Wir fangen immer damit an ein Modell der Domäne zu erstellen. Wir versuchen uns dabei möglichst nichts zu verbauen, was die Veränderlichkeit, die Erweiterbarkeit des Modells verhindert. Das bedeutet, dieses Modell ist nicht in Stein gemeißelt. Dieses Modell lebt und es verändert sich genauso wie unsere Software.

Sven:
Wenn man da einen Vergleich hernimmt: Wenn die Software ein Haus wäre und wir fangen damit an, dann darf es einem natürlich nicht passieren, dass man nach ein paar Jahren nachdem das Haus steht und man am Balkon oben steht, draufkommt: „Ich hätt jetzt gerne eine Tiefgarage, ich hab’s aber so aufgebaut, dass ich keine mehr einbauen kann.“.

Tobias:
Ich glaube, Uncle Bob, das ist ein Autor und Software-Entwickler, der sehr viel über Software-Architektur geschrieben hat, hat einmal gesagt: Das Wichtigste für einen Software-Architekten ist, sich alle Möglichkeiten so lange wie möglich offen zu halten. Das heißt, man will sich nichts verbauen und deswegen müssen wir auch schauen, dass der Code, den wir schreiben, so angelegt ist, dass wir die stabilsten Dinge – eben die Geschäftsprozesse – in der Mitte unserer Software halten und alles andere baut auf diesen Dingen auf.

Also, wenn wir jetzt eine Website bauen, ein Webshop zum Beispiel, haben wir im Kern der Software die Regeln, Bestellprozess und solche Dinge. Die Website selber, das User Interface, das man ansurft ist mehr oder weniger nur ein Plug-in in dem Ganzen. Unser Ziel ist, dass unsere Geschäftsregeln so stabil sind, dass wir auch ohne Probleme die Website komplett wegwerfen könnten und stattdessen eine App dran pluggen könnten. Oder eine andere Speicherlösung oder sonst was. Also unsere Geschäftsprozesse sind das Wichtigste und alles andere dahinter ist nur etwas, was unsere Geschäftsprozesse verwendet.

Isabel:
Ist das das, was man auch „Clean Architecture“ nennt?

Tobias:
Genau, das ist eine Form der Clean Architecture. Clean Architecture ist ein Begriff von Uncle Bob. Und nach dieser Architektur versuchen wir mittlerweile Software zu bauen. War natürlich nicht immer so, wir lernen auch immer dazu.

Isabel:
Das wollte ich zwischendurch sagen: Viele dieser Sachen haben sich im Laufe der Zeit entwickelt, oder? Vieles auch, soweit ich weiß, aus dem Team heraus. Ihr zwei, Nico und Tobi, ihr seid ja auch Leute, die sich gerne Gedanken machen, wie man es besser macht.

Nicolas:
Wir versuchen natürlich immer unsere Prozesse besser zu gestalten, Sachen zu verbessern und nachhaltiger zu gestalten. Nachhaltiger bedeutet in dem Fall, dass wir es dem Kunden einfach ermöglichen, sich neue Sachen zu wünschen, die wir dann mit weniger Arbeit einbauen können.

Isabel:
Was Sven noch erwähnt hat, war das Thema effiziente Umsetzung im Sinne des Kunden. Was tun wir in dem Bereich, um zu einem guten Preis gute Software hinzustellen?

Tobias:
Wir versuchen das Ganze effizient zu erstellen. Und versuchen auch auf Bestehenden und Bewährtes zurückzugreifen. Wir erfinden nicht jedes Mal das Rad neu – es gibt immer wieder Dinge in Programmen die gleich oder ähnlich ablaufen, zum Beispiel das Thema Authentifizierung. Da gibt es ein paar Standards, die man verwenden sollte. Und es gibt mittlerweile auch schon gute Software-Bibliotheken, die wir verwenden können, um uns Arbeit zu ersparen und vor allem auch, um Sicherheit in das Ganze hineinzubringen, weil Authentifizierung nicht trivial ist. Vor allem nicht, wenn man es gut und sicher machen will. Und deshalb verlassen wir uns da lieber auf Leute, die sehr viel Ahnung in dem Bereich haben. Es gibt von Microsoft zum Beispiel selber eigene Bibliotheken von Sicherheitsexperten.

Isabel:
Also, vertrauenswürdige Quellen, von denen ihr wisst, dass sie gute Arbeit machen?

Tobias:
Ja, genau. Und die vor allem auch schon im Einsatz sind bei großen Seiten und die gut getestet sind.

Natürlich nehmen wir auch nicht blind irgendwelche Software-Bibliotheken her, sondern wir versuchen auch immer der Hintergrund dahinter zu verstehen – was tut diese Ding – damit wir uns nicht irgendwelche Sicherheitslücken oder anderes schadhaftes Verhalten in unser Programm übernehmen.

Sven:
Ich warne meine Studenten an den beiden FHs, wo ich unterrichte, immer davor, keine sogenannten Copy-&-Paste-Programmierer zu werden. Man sagt ja immer Google und Stack Overflow sind die besten Freunde der Entwickler. Ja, passt schon, man kann dort nachschauen und was kopieren, aber man sollte es eben vorher verstanden haben, bevor man es einbaut.

Nicolas:
Bei uns landet normalerweise nie Code in einem Projekt, wenn wir ihn nicht verstanden haben. Wenn wir etwas nicht verstehen, versuchen wir es so lange bis wir es verstanden haben.

Isabel:
Was auffällig ist: Ihr sagt immer „wir“. Ihr seid keine Einzelkämpfer, ihr arbeitet in Teams. Das ist etwas was Sven vorher erwähnt hatte als Herausforderung. Wir setzten Software in Teams um, also mehrere Leute arbeiten gleichzeitig an einem großen Projekt. Eigentlich ein Rezept für Chaos, viele Köche und so weiter. Wie gehen wir damit um?

Nicolas:
Wir haben Teams in Größen von 5 bis 7 Leuten momentan. Bei uns gibt es nie Einzelkämpfer. Das bedeutet, auch wenn eventuell nur ein einziger Programmierer an einem Projekt sitzt, hat er immer einen Buddy mit dem er reden kann, mit dem er auch kleine Besprechung über den Code, der produziert wurde, oder Architekturen, die neu entworfen werden müssen, machen kann.

Sven:
Wenn man nimmt wie man früher programmiert hat, dann hat vielleicht mal jeder an einem Teil des Source Codes geschrieben und wenn du ein Pech gehabt hast, hast du das lokal getan, dann hast es zusammen kopiert und der Letzte, der gespeichert hat, hat alles überschrieben, was da war.

Das kann man natürlich nicht tun, deshalb haben wir dann aufwendig Stück für Stück, Zeile für Zeile, das Zeug zusammenfügen müssen – mergen, wie man so schön sagt.

Tobias:
Früher gab’s auch so etwas wie einen „Integration Friday“, also einen Freitag, wo alle Entwickler zusammenkommen und ihren Source Code zusammenschmeißen und versuchen, dass das Ganze wieder funktioniert. Nur mit steigender Projektgröße wird das dann ein „Integration Thursday and Friday“ und dann ist es die halbe Woche. Und dann braucht es auf einmal zwei Wochen damit die Software wieder funktioniert.

Daher hat sich der Prozess von der Continuous Integration entwickelt – also, dass man nicht mehr nur einen Tag hat an dem man integriert, sondern wir integrieren am Tag pro Team mehrere Male. Jedes Mal, wenn ein Teil der Software fertig ist, erstellen wir einen sogenannten „Pull Request“. Das heißt, dieses Feature, das entwickelt wurde, will jetzt zu den anderen Features dazu. In diesem Pull Request gehören einige Dinge dazu, zum Beispiel ein Code Review, also ein Zwei-Augen-Prinzip…

Sven:
Vier-Augen-Prinzip.

Tobias:
Immer ein Auge zudrücken! [lacht]

Vier-Augen-Prinzip eben. Und zusätzlich sind so Dinge dabei wie automatisches Testen und automatisch versuchen das Programm zu bauen, so dass wir immer in unserem Haupt-Code-Stamm eine Lösung haben, die theoretisch zum Kunden lieferbar wäre.

Isabel:
Mir kommt jetzt das Bild von einem Puzzle. Man kann sagen, jeder macht ein Puzzle-Stück und es muss hineinpassen. Man legt es dazu und so nach und nach entsteht das gesamte Bild.

Nicolas:
Genauso kann man es auch betrachten. Und früher war es halt so, dass jemand eventuell dasselbe Puzzlestück entwickelt und versucht hat es sogar noch an einer anderen Stelle rein zu prügeln – und das hat dann nicht mehr funktioniert am Donnerstag, Freitag oder Mittwoch, je nachdem wann man dann anfängt. Und dann muss man eventuell die ganze Arbeit verwerfen. Was bei uns eben nicht der Fall ist. Deswegen sind wir in der Hinsicht auch sehr effizient.

Sven:
Wir haben sogar öfters ein Sechs-Augen-Prinzip in Projekten drinnen, wo abgesehen von den vier Augen der Developer noch die zwei Augen des Product Owners drüberschauen bevor es dann zum Kunden geht. Der Product Owner ist von der Rolle her ein Stellvertreter des Kunden, der oder die sich anschaut aus Kundenblick, ob die Funktionalität jetzt funktioniert bevor man es dem echten Kunden zeigt. Das heißt, dass sehen ganz viele Augen bevor es dann wirklich in den Echtbetrieb kommt.

Isabel:
Wir zeigen unseren Kunden regelmäßig den Projekt-Fortschritt oder was eben schon gemacht wurde. Wie macht man das bzw. wie geht man damit um, wenn man so große, komplexe Software hat?

Nicolas:
Wir achten darauf, dass jedes Mal, wenn etwas in diesem großen Datenstamm, in dieses große Puzzle zurückkommt, dass wir das herzeigbar zusammen haben. Und dabei hilft uns die Continuous Delivery. Nach dem Prozess der Continuous Integration erzeugen wir anhand des Datenstamms dieses Bild aus diesem Puzzle und spielen es zum Beispiel auf unsere Testsysteme, wo auch unserer Product Owner Zugriff darauf hat und es nochmal mit seinem Augenpaar durchsieht.

Sven:
Und automatisiertes Testen kann dann auch passieren und passiert auch normalerweise bis zum automatischen Deployment in App Stores oder ähnliches.

Wichtig ist – und auch das ist anders als früher – dass es heute sehr, sehr leistungsfertige Entwicklungsumgebungen gibt, die man hier einsetzt, und die einem schon sehr helfen. Aber die werden auch immer komplexer und das heißt, ein Einstieg für neue Kollegen und Kolleginnen ist erst einmal einige Monate um überhaupt diese Continuous-Integration- und Delivery-Prozesse zu verstehen wie sie bei uns im Unternehmen funktionieren. Weil das Grundkonzept bei vielen Unternehmen gleich ist, aber die Ausprägung im Unternehmen ist immer sehr spezifisch.

Isabel:
Okay, das war ja jetzt ein richtiger Sprint durch unsere Software-Umsetzung. Unterm Strich kann man sagen, dass ein Entwickler jetzt nicht nur einfach programmiert. Da hängt viel mehr dran, als nur irgendwelche Zahlen oder Befehle einzuklopfen.

Tobias:
Ja, wir versuchen uns in die Geschäftsprozesse des Kunden rein zu finden und nach und nach zu Domain-Experten selber zu werden. Und wir müssen auch sehr viele Szenarien durchspielen im Kopf – was passiert, wenn ich das jetzt hier ändere, kann das irgendwann zu Problemen führen, wie mache ich es am besten, dass es erweiterbar bleibt.

Es ist aber auch so, dass das nie eine Einzelarbeit ist, wir kommunizieren immer dabei. Wir versuchen alle Ideen einzuholen und miteinander die beste Lösung zu finden im Team oder sogar teamübergreifend.

Nicolas:
Das stimmt genau. Wir tippen wirklich nicht den ganzen Tag Code herunter, das hat es schon lange nicht mehr bei uns gegeben und wird es auch nicht mehr geben. Wir denken wirklich sehr viel mit, wir reden viel untereinander – das Klischee ist also nicht wahr, dass der Informatiker nur vor dem Computer sitzt und einfach nur runter tippt. Wenn wir auch draufkommen, dass ein Prozess für den Kunden nicht optimal ist oder wir den optimieren könnten, dann reden wir nochmal mit unserem Product Owner und der geht dann weiter zum Kunden. Wir überlegen uns zum Beispiel auch Themen für die Usability, was für den User am besten ist und, und, und.

Also, das hört eigentlich theoretisch nie auf, wenn wir uns da nicht selbst eine Schranke setzen würden, würden wir theoretisch auch nicht mehr zum Programmieren kommen.

Sven:
Beziehungsweise, man sitzt dann mit dem Kunden in solchen Demomeetings und da sitzen ja nicht nur die Product Owner sondern auch Entwickler. Das heißt, da kriegt man auch aus erster Hand was mit. Das ist eben der Unterschied zwischen einem Standard-Programmierer, wo man halt irgendwas runterklopft, sozusagen eine „Codier-Sau“ wie es so böse oft heißt, und jemanden der Software-Entwickler oder -Entwicklerin ist nach dem modernen Muster.