Hendrik Lösch
Migration, Software Evolution, Architectur, QA, Test Automation, TDD, Clean Code
Dresden, Germany
Actions
Hendrik Lösch is a management consultant and architect at ZEISS Digital Innovation. The focus of his work is on the development and evaluation of software, based on Microsoft technologies. He also enjoys writing and talking about his work as well as his enthusiasm for clean code, software evolution and test automation in its various forms.
Area of Expertise
Topics
Times of (climate) crisis - Why sustainable software is a must!
The climate crisis is real, and it is already affecting our lives in many ways. We as developers often think that software is part of the solution to this crisis, but we don't always consider that it could also be part of the problem. This talk will take a closer look at how recent legislation in Europe, particularly in Germany, is changing the way we produce, consume, distribute and dispose of physical goods. We will also reflect on how software is involved in these processes, both in good and bad ways.
The main goal of this talk is to explain the changes we will see in the near future, but also why these are necessary due to the climate and other crises. This is to illustrate why it is important to think about these issues now and not tomorrow.
Quality! What's that?
There is a lot of discussion about the quality of software. The difficult part is that this topic is not as straightforward as it might seem at first glance. This is especially true when moving away from describing specific functions and instead focusing on general quality characteristics.
For this reason, this session will initially differentiate between the most important terms. These include "Quality Attribute" and "Quality Requirement", as well as "Functional Requirements" and "Non-Functional Requirements". The latter will be extensively explained using practical examples, clarifying their impact on architecture and the approach to testing.
We (don't) need a software architect!?!
"Software architect" - in times of agile development, this term seems almost outdated and gives the impression that there is one person who primarily creates designs that are then cast in concrete by others and never change again. This is not correct. Software changes continuously and evolutionarily. If this is not taken into account, significant problems can arise.
For this reason, the talk will give an insight into the work of software architects and show what can happen if they do not exist or their work is misunderstood. It also discusses different types of software and the composition of teams, as well as which aspects of software development can particularly benefit from software architects.
How-To Domain Model – Ein Beispiel aus der Fertigung
Ein Domain Model ist ein abstraktes Modell, das die wichtigsten Konzepte und Beziehungen innerhalb eines bestimmten Fachgebiets darstellt. Im Bereich der Fertigung kann ein Domain Model beispielsweise die verschiedenen Arten von Maschinen und Anlagen, die bei der Herstellung von Produkten verwendet werden, abbilden. Das Ziel eines Domain Models ist es dabei, die Komplexität eines Fachgebiets zu reduzieren und die Kommunikation und Zusammenarbeit innerhalb eines Entwicklungsteams sowie zwischen verschiedenen Steakholdern zu verbessern.
In diesem Vortrag klären wir zunächst die allgemeinen Theorien hinter Domänenmodellen auf Basis des Domain Driven Designs und der Enterprise Architecture Patterns von Martin Fowler. Anschließend werden wir uns auf die spezielle Anwendung von Domänenmodellen in der Fertigungsindustrie konzentrieren und Beispiele für ihre Verwendung in diesem Kontext aufzeigen. Dies ermöglicht es uns, die Vorteile des Vorgehens an realen Komplexbeispielen darzustellen, statt sie nur aus den simplifizierten Szenarien abzuleiten, die sonst in der Theorie gern verwendet werden.
Das Ziel des Vortrags ist es somit, allen Beteiligten die Wichtigkeit des Vorgehen zu verdeutlichen und einen klaren Weg aufzuzeigen wie es in realen Umgebungen eingesetzt werden kann.
Von Schichten, Ringen und Adaptern – Der Rundumschlag zum Thema Softwarearchitektur
Das Thema Softwarearchitektur ist wahrlich kein einfaches, gibt es doch dort so viele unterschiedliche Begriffe, Muster und Konzepte, die man kennen muss, um eine langfristig stabile Software designen zu können. Mit diesem Vortrag soll daher einmal ein kompletter Rundumschlag zum Thema Architekturmuster gemacht werden.
Dabei behandeln wir die wichtigsten Muster ausgehend von den Anfängen der Softwareentwicklung bis zum Nonplusultra heutiger Softwarearchitekturen. Wir starten dabei, bei den rein prozeduralen System der 70er Jahre, gehen über die klassische Schichtenarchitektur, widmen uns der Zwiebelarchitektur, machen einen Abstecher zum Domain Driven Design und landen letztendlich in der Clean-Architecture. Auf diesem Weg klären wir wichtige Begriffe wie zum Beispiel Layer und Tiers und warum diese nicht das Gleiche sind. Darüber hinaus betrachten wir aber auch wichtige Entwurfsmuster wie zum Beispiel das Domänenmodell oder das Repository.
Ziel des Vortrags ist es den Teilnehmern zu verdeutlichen welches Architekturmuster für sie tatsächlich verwendet werden sollte und wie sie die unterschiedlichen Ausprägungen zu bewerten haben.
Restructuring vs. Refactoring – Wie gräbt man ein ganzes Softwaresystem um?
Der Zahn der Zeit nagt in völlig unterschiedlichen Weisen an einem Softwaresystem. Mal kommt er in Form von geänderten Technologien (.NET Core?), mal in Form von geänderten Nutzererwartungen (Mobile?) und mal in Form von geänderten Gesetzesgrundlagen (DSGVO?). Er kann sich aber auch in der Gestalt von unsauberer Implementierung, schlechten Architekturentscheidungen oder fehlender Dokumentation entfalten. Will man ihm begegnen, bedeutet dies in aller Regel Investitionen in die Erhaltung des Wertes der Software, statt in die Steigerung ihres Funktionsumfangs.
Diesem Umstand begegnen Entwickler in aller Regel mit Refactorings. Vergleichsweise kleine Code-Änderungen, die sich groß entfalten sollen und es im Alltag dann aber leider nicht wie erwartet tun. Dies bedeutet nicht, dass Refactorings sinnlos oder gar schlecht sind. Im großen Maßstab gedacht sind sie nur eben nicht ausreichend.
Um dem auf den Grund zu gehen, schauen wir uns an was Refactorings tatsächlich sind, wie man Software im großen Maße restrukturieren kann und welche technischen, sowie organisatorischen Maßnahmen notwendig sind, um umfassendere Vorhaben zu einem Erfolg zu führen.
3D Sudoku for Advanced Players – Software Product Line Engineering
Software Product Line Engineering describes the development of a series of software products based on a common foundation of components and a unified architecture. This strategy is particularly beneficial in scenarios where multiple software products require similar functionalities but need individual customizations or variants. A notable example can be found in the Human-Machine Interfaces within the manufacturing industry, where a variety of customer-specific workflows interact with different hardware configurations.
The presentation explains the theoretical foundations of Software Product Line Engineering and demonstrates, using a practical example from the manufacturing industry, how such an architecture can be realized. The focus is on creating reusable and scalable software components that allow a wide range of product variations in different combinations.
Furthermore, the presentation addresses the efficient management of the variety of variants in software product lines. It discusses how a balanced relationship between the standardization of software modules and the necessary flexibility for customer-specific customizations can be achieved.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top