Ho Dir einen Kaffee, mach Dir entspannende Musik an, und begleite uns zur vierten Folge von The Hüb. Diesmal teilt Milan Starčević die wertvollen Erfahrungen, die er als Lead Software Engineer bei Zühlke gesammelt hat.
Herzlich willkommen auf dem Hüb – einem Ort, an dem Fachleute ihre Expertise und ihr Wissen weitergeben. Wir informieren über die Branche, gestalten deren Zukunft mit und halten Dich über alle wichtigen Trends auf dem Laufenden.
Welchen Wert hat die Konzeptualisierung beim Programmieren? Wie können wir ein selbstorganisierendes Team leiten? Was sind die nächsten großen Trends in der Softwareentwicklung?
Ho Dir einen Kaffee, mach Dir entspannende Musik an, und begleite uns zur vierten Folge von The Hüb. Diesmal teilt Milan Starčević die wertvollen Erfahrungen, die er als Lead Software Engineer bei Zühlke gesammelt hat.
Architektur ist ein hilfreiches Bild, um die Komplexität der Softwareentwicklung zu veranschaulichen. Es zeigt uns auf, dass wir nicht nur die Technologie, sondern auch die Budgets, die Stakeholder und unser Team berücksichtigen müssen. Letzten Endes ist sie das wichtigste Instrument zur Entscheidungsfindung und zur Bestimmung des richtigen Zeitpunktes, um diese Entscheidungen anzupassen.
Softwarearchitektur bedeutet lebenslanges Lernen, weil sie sich ständig weiterentwickelt. Mir gefällt, dass wir heute so viele High-Level-Konzepte haben, dass die Architektur ein Gebrauchsartikel wird. Das hat jemand aus dem Team einmal zu mir gesagt. Im Prinzip muss man Konzepte nicht von Grund auf neu erstellen, man muss sie nur kombinieren. Zum Beispiel gibt es schon viele Dienste in der Cloud. Was man wissen muss, ist, was der Dienst kann und wie viel er kostet. Dann muss man die Teile des Puzzles nur noch zusammensetzen.
Seitdem Vom Mythos des Mann-Monats geschrieben wurde, hat sich die Softwarearchitektur stark verändert. Obwohl der Autor schon damals wusste, in welche Richtung die Entwicklung gehen würde. Er meinte, dass höhere Programmiersprachen die Entwicklung einfacher und schneller machen würden. Und genau das ist ja auch passiert.
Ich bin nicht sicher, wie stark sich die Architektur noch weiterentwickeln wird, weil es in viele Richtungen gehen kann. In letzter Zeit ist zum Beispiel maschinelles Lernen relevant geworden. Quantencomputing, das jetzt noch in weiter Ferne liegt, wird ein echter Gamechanger werden.
Entscheidungen zur Architektur sollen und müssen vom gesamten Team getroffen werden. Ich halte nicht viel davon, die Aufgabe des Software Architects jemandem zuzuweisen. Wenn man einer Einzelperson die Verantwortung dafür überträgt, traut sich das Team vielleicht nicht mehr, architektonische Entscheidungen zu treffen. Schlimmstenfalls fühlt sich das Team dann weniger verantwortlich und motiviert für das Projekt.
Man kann auch den Standpunkt vertreten, dass in der Softwareentwicklung jede Entscheidung eine Architekturentscheidung ist, nur dass manche riskanter sind als andere. Früher haben wir immer gesagt, dass die Softwarearchitektur die „bösen Probleme“ löst – also solche, wo die Entscheidung schwerfällt, weil man nicht alle Konsequenzen vorhersehen kann. Heutzutage gibt es aber gar nicht mehr so viele dieser Probleme, weil es einfacher geworden ist, die Architektur weiterzuentwickeln
Ich bin ein großer Fan der Evolution von Softwarearchitektur. Ich habe schon bei mehreren Projekten gesehen, dass Veränderungen, die früher wirklich schwierig waren, heute relativ problemlos sind. Man braucht weniger Zeit, aber dafür eine gute Strategie und einige Verhandlungen mit den Beteiligten. So kann man sogar nach und nach das gesamte Produkt umwandeln, wenn der Projektrahmen das zulässt.
Wir reden dabei oft von Groß- oder Greenfield-Projekten, aber auch bei kleineren Erweiterungen muss man bei Entscheidungen an die konzeptionelle Integrität des Systems denken. Die Architektur umfasst daher alles von der Ordnerstruktur bis hin zur Large-System-Skalierung.
In der Softwareentwicklung gehen Architektur und Teamorganisation Hand in Hand. Aber wer Zeit mit der Teamorganisation verbringt, hat weniger Zeit fürs Programmieren, vor allem, wenn das Team groß und das Projekt komplex ist. Deshalb dürfen wir nicht vergessen, dass die Person in der Rolle des Tech Lead in erster Linie Software entwickelt. Man muss vor allem technisch fit bleiben. Man programmiert nicht um des Programmierens willen, sondern um Konzepte zu entwickeln, die das Team als „Best Practice“ nutzen soll. Wenn Du so als Tech Lead programmierst, kannst Du wirklich etwas bewirken.
Softwareentwicklung soll möglichst einfach sein. Deshalb verwenden die Teammitglieder ihre Konzepte untereinander wieder und müssen so das Rad nicht jedes Mal neu erfinden. Verwende einfachen Code, und zwar sparsam; man soll den Quelltext wie ein Gedicht lesen können. Hüte Dich vor „Musteritis“: So nennen wir das spaßeshalber, wenn jemand alle Vorlagen aus dem Lehrbuch verwendet. Auch deshalb muss man das Framework, das man verwendet, wirklich gut kennen. Dann kannst Du auf die Konzepte zurückgreifen, die das Framework schon bietet, anstatt neue zu entwickeln.
Für Front-End musst Du Dich mit dem HTTP-Protokoll und allem, was damit zusammenhängt, gut auskennen. Und Du musst auch verschiedene Arten von Webdiensten kennen. Du musst JavaScript, HTML und CSS beherrschen und richtig gut verstehen. Viele wollen erst mal den umgekehrten Weg gehen und zunächst ein Framework lernen. Das kann auch seine Berechtigung haben, aber ein richtiger Frontend Developer ist man nur, wenn man die Technologien, mit denen man arbeitet, in- und auswendig kennt. Wenn Du diese Technologien nicht beherrschst, sind deine Lösungen am Ende weniger effizient, oder Du verbringst viel Zeit damit, Bugs zu beheben.
Was den Überblick über die Frontend-Frameworks angeht: Ich arbeite meistens mit Angular, bin aber immer offen dafür, Projekte in anderen Technologien zu entwickeln. Angular 2+ ist ein schön gemachtes Framework mit guten Abstraktionsebenen. Auch Neulinge können damit im Allgemeinen mit der Arbeit beginnen, ohne im Detail zu wissen, wie das Framework funktioniert. Früher oder später muss man aber richtig in Angular einsteigen, um die konzeptionelle Integrität des Codes gewährleisten zu können. Wenn Du beispielsweise mit Reactive Forms arbeitest, musst Du sie korrekt und konsistent verwenden.
Bei uns ist ein Capability Owner eine Person, die einem bestimmten Bereich zugeordnet ist, in dem sie über besondere Fachkenntnisse verfügt. Diese Person behält die aufkommenden Trends in diesem Bereich im Auge und die für künftige Projekte erforderlichen Skills. Bei der Security Capability geht es in erster Linie um Ausbildung – also darum, Menschen anzuleiten, in einer bestimmten Weise zu denken, bestimmte Sicherheitspraktiken anzuwenden und Werkzeuge zu benutzen, um ihre Software sicherer zu machen.
Ich habe im Studium meinen Schwerpunkt auf Softwaresicherheit gesetzt, weil sie so viele Bereiche der Softwareentwicklung berührt. Man muss sich mit Netzwerken, Protokollen, High- und Low-Level-Programmierung sowie Prozessmanagement auskennen. Man muss wissen, wo bei der Softwaresicherheit die meisten Probleme auftauchen. Und dann muss man einen Prozess schaffen, der das gesamte Team darin unterstützt, über die gesamte Projektlaufzeit kontinuierlich sichere Software zu produzieren.
Ich interessiere mich für Teamorganisation und die entsprechenden Methoden. Sobald man Führungsverantwortung übernommen hat, muss man sich damit befassen. Von zwei Dingen bin ich absolut überzeugt: Ich glaube an Agile, aber ich zitiere nicht gerne aus dem Scrum Guide oder poche auf andere Prozesse. Für mich heißt Agile: „Erst die Leute, dann der Prozess.“ Unser Unternehmen hat beispielsweise drei Kerninteressen: die Kunden, das Unternehmen und das Team. Ich versuche, die Position in der Mitte einzunehmen und ein Gleichgewicht zwischen diesen Interessen herzustellen.
Die andere Sache, an die ich fest glaube, ist, dass sich Teams selbst organisieren und Verantwortung übernehmen sollten. Natürlich kann man unerfahrenen Software Engineers keine Verantwortung aufzwingen, aber man sollte sie ihnen Einflussmöglichkeiten bieten, sie ermutigen und Vertrauen in ihre Fähigkeiten schenken. Wenn man mit dieser Einstellung an die Sache herangeht, läuft die Selbstorganisation reibungslos.
Eigentlich hatten alle neun Projekte, an denen ich bisher bei Zühlke gearbeitet habe, unterschiedliche Prozesse. Obwohl sie alle Scrum oder Kanban oder Scrumban hießen. Wenn ich ein neues Projekt beginne, versuche ich immer erst zu verstehen, wie die Stakeholder und das Team die bestehenden Rollen und Prozesse sehen. In der Storming-Phase nach dem Tuckman-Phasenmodell der Teambildung entwickelt das Team dann eine gemeinsame Sichtweise. Aus dieser Sichtweise ergibt sich ein Prozess. Dieser Prozess entwickelt sich im Laufe der Zeit weiter, wenn das Team reifer wird oder sich verändert. Ansonsten gibt es kein Universalrezept für alle Projekte, und wenn man sich noch so sehr an Scrum klammert.
Ich versuche bewusst, mein Team nicht stark zu steuern, außer wenn ich in bestimmten Situationen die Ressourcen verteilen muss. Die Eigenverantwortlichkeit des Teams ist sehr entscheidend. Es ist mir noch nie in den Sinn gekommen, Anordnungen zu erteilen. Mein Ziel ist es in die Richtung zu steuern, wo wir Lösungen finden können. Ich finde es nach wie vor faszinierend, wie sehr ich mich auf mein Team verlassen kann.
Als ich noch jünger war, habe ich immer gedacht, dass Tech Leads alles wissen und jedes einzelne Detail kontrollieren. Inzwischen ist mir aber klar, wie viele Details ich nicht kenne. Das Allerwichtigste ist, dass die Menschen motiviert sind und sich entfalten können. Für mich hat es oberste Priorität, dass kein Teammitglied „blockiert“ wird, denn das ist sowohl für die Motivation des Teams als auch für den Kunden schlecht.
Dafür braucht man eine bestimmte Denkweise, die sich erst mit der Zeit entwickelt. Um dahin zu kommen, muss man transparent über alle Aspekte eines Projekts. Man muss das Team auch dazu anhalten, sich die Bedürfnisse des Kunden klarzumachen. Je nach Auftraggeber und Projekt kann das natürlich schwieriger oder einfacher sein.
Ich spreche hier von Kunden, weil wir uns in einer Marktwirtschaft bewegen. Aber in jeder Art von Wirtschaft müssten wir in irgendeiner Weise zur Gesellschaft beitragen. Jedes Wirtschaftssystem braucht sowohl Versicherungsprojekte als auch Projekte für riesige Telekommunikationsunternehmen mit einer Millionenkundschaft. Unsere Aufgabe ist es, mit unserer Arbeit einen Nutzen für beide zu schaffen.
Damit das gut gelingt, braucht man schon eine gewisse Begeisterung und einen weiten Blickwinkel. Der Trick besteht darin, darüber nachzudenken, warum der Kunde etwas will, bevor man es umsetzt. Die Absicht spielt immer eine große Rolle. Je nachdem, wie viel Erfahrung der Kunde in der Zusammenarbeit mit Softwareunternehmen hat, kann seine Lösung technisch besser oder schlechter gerechtfertigt sein.
Was wir oft feststellen, ist, dass die Lösung, die der Kunde wünscht, nicht die Lösung ist, die er braucht. Dann muss man den Kunden überzeugen, aber auf diplomatische Weise. Der Kunde wird immer zufriedener sein, wenn man gemeinsam mit ihm den Weg zu einer besseren Lösung erarbeitet.
Ich interessiere mich für Quantencomputing, obwohl ich glaube, dass das nie richtig kommerziell werden wird. Wir werden es nicht für Tabellen oder Katzenvideos verwenden, weil es für solche Aufgaben keine Leistungsvorteile bietet. Aber bei hochkomplexen Berechnungen leistet es Unglaubliches. Es kann zum Beispiel das Wetter wesentlich genauer vorhersagen oder die Proteinfaltung besser berechnen. Es ist nur eine Frage der Zeit, bis wir die kritische Anzahl von Qubits für die „Quantenüberlegenheit“ erreicht haben. Das ist der Punkt, an dem ein Quantencomputer ein Problem lösen kann, vor dem ein klassischer Computer kapitulieren muss.
Andererseits wird es für die einzelnen Software Engineers einen riesigen Sprung bedeuten, weil es auf einer völlig anderen Architektur und Rechnerstruktur beruht. Es setzt auch eine ganz andere Mathematik voraus, die man erst lernen muss.
Interessant ist auch, dass die Rechenleistung der Quantencomputer so groß sein wird, dass sie die derzeitigen Verschlüsselungstechnologien knacken und die Softwaresicherheit erheblich gefährden werden. Bis die Quantenkryptographie in alle Computersysteme integriert ist, wird die Verwendung vermutlich stark reguliert sein.
Es gibt Initiativen, Quantencomputing kommerziell anzubieten, so wie Microsoft es mit Azure vorhat. Mit Q# kann man schon Quantenprogramme schreiben, die derzeit über einen Simulator auf einem klassischen Server ausgeführt werden. Im nächsten Schritt muss Microsoft nur noch die zugrundeliegende Hardware austauschen, wenn diese soweit ist. Auf diese Weise kannst Du mit Q# leicht Quantenberechnungen durchführen.
Ich finde das faszinierend, weil es sich wie Science-Fiction anfühlt, aber doch allmählich in greifbare Nähe rückt.
Milan ist Principal Consultant und arbeitet seit November 2013 bei Zühlke. Er war Leiter eines technischen Teams mit den Schwerpunkten Softwarearchitektur, Entwicklung, Prozess und Coaching. Er hat an neun Kundenprojekten aus verschiedenen Branchen mit verteilten Teams und Kunden an über zehn Standorten mitgearbeitet. Die Projekte reichten von kleinen Prototypen und Teams mit einer Dauer von zwei Monaten bis hin zu großen, mehrjährigen Unternehmensprojekten mit mehreren Teams und einem Scaled Agile Framework (SAFe).
