
Am 09. Oktober 2024 wurde im Rahmen einer feierlichen Veranstaltung im Messequartier Dornbirn der KMU-Preis des Landes Vorarlberg 2024 verliehen. FORTIX wurde als Gewinner in der Kategorie Dienstleistung/Tourismus ausgezeichnet!
Eine 7-köpfige Jury hat die Gewinner in den Kategorien Handel, Dienstleistung/Tourismus und Gewerbe/Handwerk ausgewählt. Die Fortix GmbH konnte sich gegen starke Mitbewerber durchsetzen und den begehrten Preis entgegennehmen.

## Ein großes Dankeschön

Wir freuen uns sehr über diese Auszeichnung und bedanken uns bei allen, die uns auf unserem Weg begleitet haben.
Ein besonderer Dank gilt unseren Kunden, die uns ihr Vertrauen schenken und uns immer wieder herausfordern, innovative Lösungen zu entwickeln.

![Alle KMU-Preis 2024 Preisträger](/images/blog/kmu-preis-2024/kmu2024_preistraeger.webp)

### Der KMU-Preis Vorarlberg

Der KMU-Preis Vorarlberg wird jährlich durch eine Initiative der Vorarlberger Nachrichten und der Wirtschaftskammer Vorarlberg verliehen.
Der 16. KMU-Preis wurde in den Kategorien Handel, Dienstleistung/Tourismus und Gewerbe/Handwerk vergeben. Die diesjährigen Partner des KMU-Preises
waren Land Vorarlberg, Hypo Vorarlberg, Vorarlberger Landes-Versicherung und Autohaus Lins.

#### Weitere Links:

- [KMU-Magazin 2024](https://issuu.com/medienhaus.com/docs/kmu2024_journal/16)
- [Video KMU-Preis 2024](https://www.youtube.com/watch?v=GjK8EA-7qlM)

<small>Bilder © Vorarlberger Nachrichten</small>


Sieger KMU-Preis Vorarlberg 2024


In der Welt der Softwareentwicklung wird oft über technische Schulden gesprochen, häufig in einem negativen Kontext. Doch wie bei vielen Dingen im Leben gilt: Technische Schulden sind nicht per se schlecht. Tatsächlich können sie strategisch genutzt werden, um bestimmte Ziele zu erreichen. In diesem Blog möchte ich die Balance zwischen den Vorteilen und den Risiken technischer Schulden beleuchten und zeigen, wie ein bewusster Umgang mit ihnen die Produktentwicklung unterstützen kann.

#### Was sind Technische Schulden?

Der Begriff "Technical Debt" (Technische Schulden) wurde 1992 vom Softwareentwickler Ward Cunningham geprägt. Er verwendete diese Metapher, um zu beschreiben, wie kurzfristige Entscheidungen bei der Softwareentwicklung, die aus Zeitdruck oder Kompromissen resultieren, langfristige Nachbesserungen erforderlich machen können.

Technische Schulden entstehen, wenn bei der Entwicklung von Software bewusste Kompromisse eingegangen werden, um kurzfristig bestimmte Ziele zu erreichen. Diese Entscheidungen führen oft zu **zusätzlichen Nachbesserungen**, die nötig sind, weil die Entwicklung entweder schneller oder nachlässiger durchgeführt wurde. Dabei kann es sich um suboptimale Lösungen handeln, die es ermöglichen, eine Deadline zu erreichen oder eine schnelle Markteinführung zu realisieren.

#### Die Unterscheidung von Technischer Schuld nach Martin Fowler

Der bekannte Softwarearchitekt **Martin Fowler** hat das Konzept der technischen Schulden weiter differenziert, indem er sie in vier Kategorien unterteilt: **leichtsinnig** und **umsichtig** sowie **absichtlich** und **versehentlich**. Diese Unterscheidung hilft dabei, besser zu verstehen, wie technische Schulden entstehen und welche Herangehensweise dahinter steckt. Fowler teilt die technische Schuld in vier Quadranten auf, die je nach Bewusstsein und Absicht variieren.

**1. Leichtsinnig und versehentlich**

Diese Art von technischer Schuld entsteht, wenn Entscheidungen getroffen werden, ohne das notwendige Wissen oder Verständnis zu haben. Ein Beispiel hierfür wäre: "Was ist Layering?" – ein Zeichen dafür, dass die Entwickler grundlegende Prinzipien oder Best Practices nicht kennen. Hier resultieren die Schulden aus Unwissenheit und unüberlegtem Handeln.

**2. Leichtsinnig und absichtlich**

In diesem Fall weiß das Team, dass es eine schlechte Entscheidung trifft, wählt diesen Weg aber bewusst aus, oft aufgrund von Zeitdruck oder mangelnden Ressourcen. Ein klassisches Beispiel ist: "Wir haben keine Zeit für Design." Hier wird absichtlich auf Qualitätsstandards verzichtet, um schnell zu liefern, obwohl den Entwicklern die Konsequenzen klar sind.

**3. Umsichtig und absichtlich**

Diese Form der technischen Schuld entsteht, wenn man sich der Risiken und Konsequenzen bewusst ist, aber trotzdem eine informierte Entscheidung trifft, weil es unter den gegebenen Umständen notwendig ist. Ein typisches Szenario wäre: "Wir müssen jetzt das Produkt liefern und müssen mit den Problemen fürs Erste leben." Hier wird eine bewusste Risikoabwägung vorgenommen, um ein vorrangiges Ziel, wie eine rechtzeitige Markteinführung, zu erreichen.

**4. Umsichtig und versehentlich**

In dieser Kategorie entstehen technische Schulden aus Fehlern, die erst im Nachhinein als solche erkannt werden. Das Team hatte ursprünglich die besten Absichten und glaubte, eine gute Entscheidung getroffen zu haben, stellt aber später fest, dass es besser hätte gehen können. Ein Beispiel hierfür wäre: "Jetzt wissen wir, wie wir es hätten machen sollen." In diesem Fall wird aus den Fehlern gelernt, und künftige Projekte können davon profitieren.

![](/images/blog/technical-debt/technical-debt-dra-of-martin-fowler.png 'Darstellung der technischen Schulden nach Martin Fowler')

Diese Unterscheidung von Martin Fowler zeigt, dass nicht alle technischen Schulden gleich sind. Der Kontext und die Intention hinter den Entscheidungen spielen eine große Rolle, wenn es darum geht, wie kritisch diese Schulden bewertet werden sollten und wie man sie zukünftig vermeiden kann.

#### Technische Schulden sind nützlich, wenn...

- **Wichtige Deadlines erreicht werden müssen:** Es kann sinnvoll sein, bestimmte Qualitätsstandards zu senken, um ein Projekt termingerecht abzuschließen.

- **Die schnelle Markteinführung entscheidend ist:** In stark umkämpften Märkten zählt oft die Zeit. Ein Produkt kann schneller auf den Markt gebracht werden, auch wenn der Code nicht perfekt ist.

- **Ein MVP (Minimum Viable Product) gebaut wird:** Beim Start eines neuen Projekts ist es oft wichtiger, schnell Feedback vom Markt zu erhalten, als perfekten Code zu schreiben.

Doch auch wenn technische Schulden in diesen Fällen nützlich sein können, sollten sie so schnell wie möglich wieder abgebaut werden. Das bedeutet, dass nach der Erreichung kurzfristiger Ziele Zeit für Refactoring eingeplant werden sollte, um die entstandenen Schulden zu beseitigen.

#### Warum Technische Schulden nicht ignoriert werden sollten

Technische Schulden werden häufig als Synonym für schlechten Code verwendet. Es gibt jedoch einen wesentlichen Unterschied: Technische Schulden sind das bewusste Akzeptieren von Kompromissen in der Qualität zugunsten von kurzfristigen Zielen, während schlechter Code oft aus Nachlässigkeit oder fehlendem Know-how entsteht.

Technische Schulden können auf unterschiedliche Weise entstehen. Es ist wichtig, nicht nur die unmittelbaren Ursachen während der Entwicklungsphase zu betrachten, sondern auch die langfristigen Effekte, die durch das Nicht-Weiterentwickeln der Software auftreten können.

#### Technische Schulden während der Entwicklung

Technische Schulden entstehen oft direkt im Entwicklungsprozess, insbesondere wenn Teams unter starkem Zeitdruck stehen oder Anforderungen unklar formuliert sind. In solchen Situationen werden häufig Kompromisse bei der Codequalität eingegangen. Einige der häufigsten Ursachen sind:

- **Zeitdruck:** Wenn ein Projekt schnell fertiggestellt werden muss, wird häufig der saubere, durchdachte Code zugunsten von schneller umsetzbaren, aber weniger wartungsfreundlichen Lösungen vernachlässigt. Dies kann kurzfristig zu einem fertigen Produkt führen, erfordert aber in der Zukunft aufwendige Nachbesserungen.

- **Unklare Anforderungen:** Wenn die Anforderungen an ein Softwareprojekt nicht präzise definiert sind, besteht die Gefahr, dass Entwickler Lösungen umsetzen, die später überarbeitet werden müssen. Änderungen in den Anforderungen führen oft zu schnellen Anpassungen, die nicht optimal integriert sind und somit technische Schulden erzeugen.

- **Unzureichende Tests:** Wenn Tests nicht ausreichend oder gar nicht durchgeführt werden, steigt das Risiko von Bugs und Fehlfunktionen, die später behoben werden müssen. Dieser Mangel an Qualitätssicherung führt zu einem langfristigen Wartungsaufwand.

- **Schlechte Dokumentation:** Eine unvollständige oder unklare Dokumentation erschwert es den Entwicklern, den Code zu verstehen und zu pflegen. Dies führt zu Mehraufwand, wenn der Code später angepasst oder erweitert werden soll.

- **Unsauberer Code:** Suboptimale Code-Strukturen oder übermäßig komplexer Code, der schlecht lesbar oder wartbar ist, sind ein weiteres klassisches Beispiel für technische Schulden. Solche Codefragmente müssen in der Regel bei späteren Updates refactort oder gar neu geschrieben werden, um die Wartbarkeit und Erweiterbarkeit der Software zu gewährleisten.

#### Technische Schulden durch Nicht-Entwicklung

Technische Schulden entstehen nicht nur aktiv während der Entwicklung, sondern können sich auch durch das **Nicht-Weiterentwickeln** der Software anhäufen. Software, die nicht regelmäßig gepflegt wird, gerät oft technisch ins Hintertreffen. Diese „unsichtbaren“ technischen Schulden können genauso schwerwiegende Auswirkungen haben wie die Schulden, die durch aktive Entwicklung entstehen:

- **Technologischer Wandel:** Technologien und Best Practices in der Softwareentwicklung ändern sich stetig. Neue Programmiersprachen, Tools oder Frameworks bieten oft effizientere oder sicherere Möglichkeiten, Software zu entwickeln. Wird eine bestehende Software nicht regelmäßig modernisiert oder angepasst, entsteht eine Diskrepanz zwischen dem aktuellen Stand der Technik und der eingesetzten Technologie, was die zukünftige Wartung und Erweiterung erheblich erschweren kann.

- **Veraltete Bibliotheken und Frameworks:** Bibliotheken und Frameworks werden regelmäßig aktualisiert, um neue Funktionen zu integrieren, Sicherheitslücken zu schließen oder die Performance zu verbessern. Wenn eine Software auf veralteten Abhängigkeiten aufbaut und diese nicht regelmäßig aktualisiert werden, kann das zu Inkompatibilitäten, Sicherheitsrisiken oder eingeschränkter Funktionalität führen. Das Nachziehen dieser Updates kann dann aufwendiger und risikoreicher werden, je länger es hinausgezögert wird.

- **Neue Architekturkonzepte:** In der Softwarearchitektur entstehen immer wieder neue Paradigmen und Designmuster, die es erlauben, Systeme skalierbarer, robuster oder leichter wartbar zu gestalten. Unternehmen, die ihre Architektur nicht an diese neuen Konzepte anpassen, könnten langfristig darunter leiden, dass ihre Software schwerer erweiterbar oder weniger effizient ist. Auch das Ignorieren dieser Fortschritte kann technische Schulden akkumulieren, die später aufwändig beseitigt werden müssen.

Diese Art von technischen Schulden, die sich durch Nicht-Weiterentwicklung ansammeln, sind oft schwer zu erkennen, da sie nicht sofort sichtbar sind. Dennoch sind sie genauso kritisch, da sie die Flexibilität und Zukunftsfähigkeit der Software beeinträchtigen.

#### Wie technische Schulden abgebaut werden können

Technische Schulden müssen ernst genommen und strategisch angegangen werden, um langfristig eine stabile Codebasis zu gewährleisten. Hier sind einige Wege, um technische Schulden zu verringern:

- **Bewusster Umgang mit technischen Schulden** Technische Schulden sollten dokumentiert und überwacht werden. Es ist wichtig, stets im Auge zu behalten, wo und warum sie entstehen.

- **Feedback von Entwicklern einholen** Die Entwickler wissen am besten, wo sich technische Schulden verbergen. Regelmäßige Team-Meetings können helfen, diese Schulden zu identifizieren.

- **Automatisierte Tests und Tools verwenden** Tools wie [SonarQube](https://www.sonarsource.com/products/sonarqube/) können dabei helfen, technische Schulden zu visualisieren und die Codequalität zu verbessern.

- **Refactoring-Zeit einplanen** Es sollte in jedem Sprint Zeit für Aufräumarbeiten (Refactoring) eingeplant werden, um technische Schulden kontinuierlich abzubauen.

#### Das Projektmanagement von der Wichtigkeit überzeugen

Eine der größten Herausforderungen beim Umgang mit technischen Schulden ist, das Projektmanagement davon zu überzeugen, dass ihre Beseitigung wichtig ist. Hier ist es entscheidend, die **Ziele des Unternehmens** mit der Notwendigkeit des Abbaus technischer Schulden in Einklang zu bringen.

Drei Argumente können helfen, das Projektmanagement zu überzeugen:

- **Zahlen sprechen lassen:** Konkrete Metriken, die die negativen Auswirkungen technischer Schulden auf die Produktivität zeigen, sind oft das beste Argument.

- **Langfristige Probleme aufzeigen:** Technische Schulden, die nicht behoben werden, verschlimmern sich über die Zeit und können zukünftige Projekte erheblich verlangsamen.

- **Risikomanagement:** Der Aufbau technischer Schulden ist vergleichbar mit einem wachsenden Risiko. Je länger sie ignoriert werden, desto schwieriger und teurer wird ihre Beseitigung.

#### Fazit

Technische Schulden sind ein unvermeidlicher Teil der Softwareentwicklung. Sie können, wenn sie bewusst eingesetzt werden, sogar ein wertvolles Werkzeug sein, um schnelle Ergebnisse zu erzielen. Wichtig ist jedoch, dass sie stets im Auge behalten und so schnell wie möglich abgebaut werden, um langfristige Stabilität zu gewährleisten. Ein transparenter und geplanter Umgang mit technischen Schulden hilft dabei, die Balance zwischen Entwicklungsgeschwindigkeit und Codequalität zu wahren.

#### Links

- [Martin Fowler Technical Debt](https://martinfowler.com/bliki/TechnicalDebt.html)
- [Martin Fowler Technical Debt Quadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)
- [LeadDev Technical Debt](https://leaddev.com/tech/tech-debt-engineering-leaders-how-shortcut-today-impacts-tomorrow?utm_source=tldrwebdev)
- [Engineering Leadership Technical Debt](https://newsletter.eng-leadership.com/p/engineers-guide-to-convincing-your?utm_source=tldrwebdev)
- [DevBoost Der richtige Umgang mit technischen Schulden](https://devboost.com/blog/tipps-fuer-den-richtigen-umgang-mit-technischen-schulden?utm_source=9-3)


Technische Schulden: Fluch oder Segen für die Softwareentwicklung?


Trotz guten Entwicklern und einem erfahrenen Projektteam ist der Erfolg eines Software Produktes nicht immer automatisch gewährleistet. Jahrelang eingespielte Entwicklerteams, ausreichend vorhandenes Know-How sowohl in Domäne als auch Tech-Stack gepaart mit genügend zeitlicher Flexibilität bleiben oft das Wunschszenario. Kurz gesagt, die Ressourcen sind knapp, die gesetzten Ziele hoch. Es gilt also mit diesen Rahmenbedingungen umzugehen, die Produktivität zu maximieren und die internen Voraussetzungen für einen effizienten Entwicklungsprozess zu schaffen.

Und dennoch ist in vielen Fällen genau hier noch Luft nach oben. Unklare Strukturen und Prozesse, mangelnder Fokus auf das Kernprodukt, unproduktive Meetings und teils ausbaufähige Architekturentscheidungen sind nur einige der Hürden, mit denen sich Produkt- und Entwicklerteams auseinandersetzen müssen. Gerade wenn Ressourcen nicht immer ausreichen und die Zeit drängt, können die richtigen internen Handgriffe dem Team die notwendige Struktur, Effizienz und Motivation verleihen.

#### Produktmanagement: Die Richtung festlegen und halten

Die Basis für einen optimalen Produktentwicklungsprozess entsteht bereits bei der Ausarbeitung der Produkt Strategie. Im Mittelpunkt, eine klar definierte Product Roadmap. Diese Roadmap sollte nicht nur kurzfristige Ziele festlegen, sondern auch eine klare Mission für das Produkt definieren. Ein gemeinsames Verständnis der Mission schafft Identifikation im Team, fördert die Zusammenarbeit und hilft dabei, die Entwicklung auf das Wesentliche zu konzentrieren. Dabei sollten ständige Richtungsänderungen und Insellösungen vermieden werden, da diese die Entwicklung verlangsamen und das Team demotivieren. Natürlich ist klar, dass auf gewisse Dynamiken im Markt reagiert werden muss und diese die Strategie beeinflussen können, allerdings haltet sich die Agilität an dieser Stelle idealerweise noch etwas in Grenzen.

#### Strukturierte Abläufe und klare Rollenverteilungen

Es hat gute Gründe, wieso Scrum der Grundstein für nahezu alle modernen Software Projekte ist. Es verteilt eindeutige Aufgabenbereiche, gibt einen transparenten und einheitlichen Arbeitsablauf vor und erlaubt somit für Flexibilität, Reaktionsschnelligkeit und Effizienz. Obwohl es nicht in allen Fällen notwendig ist einen Scrum-Prozess laut Lehrbuch einzuführen, sollte man sich den Vorteilen der Grundprinzipien von Scrum bewusst sein und bei Bedarf einen adaptierten Prozess implementieren. Das Ziel muss sein:

- Gut vorbereitete PI- und Sprintplanungen, welche durchdachte und ausführlich definierte Arbeitspakete verabschiedet und die Arbeitsbelastung ideal priorisiert
- Kompakte und regelmäßige Standup Meetings während des Sprints um den Informationsaustausch hochzuhalten und unnötige Meetings zu vermeiden
- Klare Rollenverteilung für direkte Kommunikation und kurze Entscheidungswege
- Gezieltes Dokumentieren von kritischen Informationen als Kriterium für Definition of Done
- Ständige Reflexion des Arbeitsprozesses und Team Dynamik durch regelmäßige Retrospective Meetings

Diese Grundprinzipien erlauben dem Entwicklungsteam vollen Fokus und Stabilität. Zusätzlich dazu wird es für neue Teammitglieder leichter sich schnell in das Projekt zu integrieren und Schritt für Schritt durch strukturierte Planung und direkte, regelmäßige Kommunikation den gewünschten Output zu produzieren.

#### Saubere Anforderungen und eine effektive Teststrategie

Viele haben es wahrscheinlich schon mitgemacht: Das Planungsmeeting geht wiedermal länger als geplant, Grundsatzdiskussionen nehmen die eigentlich wertvoll eingeplante Zeit für die Definition der Akzeptanzkriterien ein und jeder ist froh, wenn man das mühselige Meeting hinter sich lassen und mit der Umsetzung starten kann. Das Problem dabei, die geplanten Stories wurden nicht mehr im notwendigen Detail besprochen, Anforderungen wurden schlampig definiert und es herrscht zu viel Interpretationsspielraum. Dementsprechende Unsicherheit, Fehlinterpretationen und Missverständnisse während der Implementierung führen nun zu möglichen ungewünschten Outcomes und kostspieligen Verzögerungen.

Man sieht, die beiden oben angesprochenen Themen sind auch die Basis für ein sauberes Anforderungsmanagement. Aufbauend darauf ist es ausschlaggebend, die Lösungsspezifikation der Arbeitspakete nicht nur zu diskutieren, sondern auch vollständig und verständlich zu verschriftlichen. Somit wissen sowohl Entwickler und Product Owner genau was definiert wurde, das Risiko für Missverständnisse und zeitaufwendige Abstimmungsmeetings wird minimiert, und die Voraussetzungen für einen effizienten Review und Testing Prozess sind geschaffen.

Werden die Features nun on-time abgeschlossen und präsentiert, kann parallel direkt mit dem Testing angefangen werden während der nächste Sprint bereits in Entwicklung ist. Ergänzend zum bestehenden automatisierten Testing werden somit durch _Continuous Testing_ potenzielle Fehler frühzeitig erkannt und behoben. Dies ermöglicht nicht nur eine höhere Produktqualität, sondern reduziert auch das Risiko von teuren Nacharbeiten und langwierigen Testphasen vor dem Release.

#### Modularisierung von Architekturen für Flexibilität und Skalierbarkeit

Gerade in größeren Softwareprojekten mit einer Vielzahl an Entwicklern, oftmals sogar organisiert in mehreren Teams, kann eine suboptimale Architektur schnell mal zum Bottleneck werden. Je länger das Projekt andauert und die Applikation wächst, desto anspruchsvoller ist in der Regel die Entwicklung jedes einzelnen neuen Features und umso wichtiger ist der Fokus auf einen hoch-qualitativen und vor allem wartbaren Code.

Durch die Aufteilung eines komplexen Systems in unabhängige Module (z.B. bei Domain-Driven-Design) wird die Architektur klar strukturiert und getrennt, was die Flexibilität und Erweiterbarkeit erheblich verbessert. Modularisierung ermöglicht es, Änderungen in einem Teil des Systems vorzunehmen, ohne den gesamten Code zu berühren. Dies trägt zur Fehlerreduzierung bei und erleichtert es, neue Funktionen hinzuzufügen oder bestehende zu optimieren, ohne das gesamte System zu gefährden. Darüber hinaus fördert die Modularisierung die Zusammenarbeit in großen Entwicklerteams, da diese unabhängig voneinander an verschiedenen Teilen der Applikation arbeiten können.

#### Fazit

Um das volle Potenzial eines Entwicklungsteams auszuschöpfen benötigt es angefangen vom Produktmanagement bis hin zur Softwarearchitektur genügend Struktur, solide Planung, klare Rollenverteilung und gezielte Kommunikation. Auch wenn ein funktionierender Prozess gefunden wurde und die Produktivität stimmt, darf man sich nicht darauf ausruhen und muss sich laufend an die sich verändernden Situationen anpassen.

Ganz nach unserem Motto “Good people, good projects” kann natürlich der Entwicklungsprozess noch so feinjustiert sein, es braucht am Ende immer das richtige Team um den Projekterfolg sicherzustellen.


Erfolgsfaktoren für einen effizienten Entwicklungsprozess


#### Jakob’s Law

###### “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.”

Benutzer sind an bestimmte Designelemente und Interaktionen gewöhnt, die sie beim Verwenden verschiedener Websites und Anwendungen erleben. Durch die Verwendung vertrauter Design Patterns können Sie eine intuitivere und benutzerfreundlichere Erfahrung für Ihre Zielgruppe schaffen.

![Youtube Redesign 2017: Etablierte Navigation bleibt](/images/blog/laws-of-software-development/jakobs-law-youtube.jpg)

#### Hofstadter’s Law

###### “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

"Wie lange wird es dauern?“ ist eine der gefürchtetsten Fragen in der Softwareentwicklung. Hofstadters Gesetz beschreibt die Tendenz, dass Projekte und Aufgaben häufig mehr Zeit in Anspruch nehmen als ursprünglich angenommen. Sogar wenn bereits Verzögerungen und Puffer für Unvorhersehbarkeiten eingeplant wurden.

In Software-Projekte gibt es zahlreiche Gründe für Verzögerungen: Unseriöse Angebote und Aufwandschätzungen, falsche Annahmen, unklare Spezifikationen, Fokus auf unwesentliche Dinge, Legay Code, permanente Change-Requests, Angst Entscheidungen zu treffen, etc.

#### The 90-90 Rule

###### “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Die 90-90-Regel spiegelt (etwas überspitzt) wider, dass Softwareprojekte oft länger dauern als erwartet. Die ursprünglich geplante Entwicklungsdauer wird aus diversen Gründen (siehe Hofstadter’s Law) überschritten. Auch wenn man zu Beginn große Schritte macht und die Entwicklung wie geplant voranschreitet, kann es – je näher der Go-Live Termin kommt – zu Verzögerungen kommen.

#### Brooks’s law

###### “Adding manpower to a late project makes it later.”

Das Gesetz stammt aus Fred Brooks' Buch "The Mythical Man Month" von 1975. Es befasst sich mit der Annahme, dass Teammitglieder und benötigte Monate austauschbar sind. Dies ist jedoch insbesondere in der Softwareentwicklung nicht zwingend der Fall. Warum? Aufgrund der Zeit, die benötigt wird, um Personen über den aktuellen Stand des Projekts auf dem Laufenden zu halten und sie in den Prozess zu integrieren. Zudem gibt es nicht immer die Aufgaben, die in kleinere Subtasks aufgeteilt werden können und gleichzeitig abgearbeitet werden.

![“You cannot have a baby in one month by getting nine women pregnant.”](/images/blog/laws-of-software-development/brooks-law.png)

#### Murphy's Law

###### “If there is a wrong way to do something, then someone will do it.”

Dies ist das bekannteste und universellste Gesetz auf dieser Liste. Murphys Gesetz ist in allen Bereichen des Projektmanagements, der Softwareentwicklung und des Lebens im Allgemeinen sichtbar.

#### Pareto Principle

###### "80% of the effects come from 20% of the causes."

Ein Klassiker! Das Paretoprinzip kann auf viele Bereiche der Arbeit und des Lebens angewandt werden. In der Softwareentwicklung können bedeutende Verbesserungen erzielt werden, indem man den Fokus auf die Funktionen legt, die dem User einen Mehrwert liefern. Zu früh und zu oft verliert man sich im Detail.

Sollte das Paretoprinzip immer berücksichtigt werden. Nein! Es gibt Fälle, in denen es von Vorteil ist, wenn man frühzeitig alle Eventualität berücksichtigt.

#### Dunning–Kruger Effect

###### "Low performers often struggle to recognize the skills and competence of others, leading them to consistently view themselves as better, more capable, and more knowledgeable than others."

Der Dunning-Kruger-Effekt besagt, dass Menschen mit geringen Fähigkeiten oft ihre eigenen Fähigkeiten überschätzen und die Tiefe des benötigten Fachwissens nicht erkennen. Weniger kompetente Personen halten sich oft für sehr kompetent, während kompetentere Personen ihre Fähigkeiten realistischer einschätzen können. In der Softwareentwicklung trifft man häufig auf dieses Phänomen.

![Zu Beginn ist die Lernkurve steil...](/images/blog/laws-of-software-development/dunning-kruger-effect.png)

#### Segal’s Law

###### “A man with a watch knows what time it is. A man with two watches is never sure.”

Hier geht es um die Daten und die Datenqualität – genauer gesagt das Konzept „Single source of truth“ (SSOT). Ein Unternehmen sammelt alle Daten an einem Ort. Dieser allgemeingültige Datenbestand liefert korrekte und verlässliche Daten.

Mehrere Datenquellen ohne SSOT können u.a. zu Verwirrung und Inkonsistenzen führen.

#### DRY (Don't Repeat Yourself)

###### "Every piece of knowledge must have a single, unambiguous representation within a system."

Das DRY-Prinzip besagt, dass in einem Softwareprojekt dieselbe Information oder Logik nicht an mehreren Stellen dupliziert werden sollte. Stattdessen sollte sie an einer einzigen Stelle verwaltet werden. Dies fördert die Wartbarkeit, reduziert das Risiko von Fehlern und vereinfacht Änderungen, da Aktualisierungen nur an einer Stelle vorgenommen werden müssen.

#### Gall’s law

###### “A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.”

Wenn man ein neues System entwickelt, sollte man schrittweise vorgehen. Galls Gesetz liefert einen guten Grund, die Entwicklung von Softwareprodukten in unterschiedliche Etappen zu unterteilen. In der Praxis setzt man dabei auf Werkzeuge wie Prototyping, PoCs und MVPs. Wenn alles funktioniert, kann man schrittweise weiterentwickeln und neue Funktionen hinzufügen.

![Step-by-Step zum Ziel mit Prototyping und MVPS](/images/blog/laws-of-software-development/galls-law.png)

#### KISS (Keep it Simple, Stupid)

###### "Simplicity is the ultimate sophistication."

Dieses Prinzip rät dazu, Software so einfach wie möglich zu halten, um unnötige Komplexität zu vermeiden. Einfache Lösungen sind oft leichter zu verstehen, zu warten und zu debuggen. Klingt simple oder?

#### Eagleson’s law

###### “Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

Mit sechs Monaten zählt Eagleson zu den Optimisten. Wie dem auch sei. Sein Gesetz unterstreicht die Notwendigkeit von Clean-Code, Standards und Kommentaren. Nach einer Weile kann selbst der ursprüngliche Programmierer seinen Code nicht mehr entwirren. Ich spreche da aus eigener Erfahrung…

#### Lubarsky’s law

###### “There’s always one more bug.”

Trotzt aller Bemühung und einhalten von Best-Practice-Ansätzen: Man wird immer noch einen Bug oder eine vermeintliche Optimierung finden. Die Arbeit ist nie abgeschlossen. Was lehrt uns das Gesetz: Nimm dich in Acht vor Perfektionismus! Es kann Zeit, Geld und Nerven kosten.

#### Knuth’s Optimization Principle

###### “Premature optimization is the root of all evil.”

Meiner Meinung nach trifft das nicht immer zu. Beispiel: Wenn wir wissen, dass ein bestimmter Teil eines Systems entscheidend für die Leistung ist und es einen besseren Ansatz als die aktuelle Implementierung gibt, sollte man zumindest über die Alternative diskutieren.

So oder so, in etwa 90 % der Fälle trifft dieses Prinzip zu: Wenn wir zu früh und zu stark optimieren, besteht die Gefahr, dass man das große Ganze aus den Augen verliert und wertvolle Zeit verschwendet.

#### YAGNI (You Aren't Gonna Need It)

###### "Always implement things when you actually need them, never when you just foresee that you need them."

“Nur für den Fall, dass wir sie brauchen” oder “irgendwann wird uns das Helfen”. Stop! YAGNI rät davon ab, Funktionalität oder Features vorzeitig hinzuzufügen. Stattdessen sollte man sich auf die aktuellen Prioritäten fokussieren.

#### Sayre’s Law

###### “In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake.”

Intensive Diskussionen sind wichtig. Manchmal wird zu viel Zeit für Nebenschauplätze verschwendet. Wenn man stundenlang über Dinge debattiert, die keinen Mehrwert bringen, ist das Zeitverschwendung. Daher gilt die Faustregel: Die Diskussionszeit sollte proportional zur Wichtigkeit des Problems sein.

![Fokus auf die wichtigen Themen](/images/blog/laws-of-software-development/sayres-law.png)

#### Parkinson’s Law of Triviality

###### "The time spent on any agenda item will be in inverse proportion to the sum involved."

Ähnlicher Ansatz wie Sayre’s Law. Das Gesetz besagt, dass Menschen tendenziell mehr Zeit und Energie für unwichtige Angelegenheiten verschwenden. In der Softwareentwicklung kann es zu ausgeschweiften Diskussionen über Details wie Formatierungen kommen, während bei tiefgreifende Architektur- oder Designentscheidungen wenig Input geliefert wird.

![Das berühmte Beispiel von Parkinson: Bikesheeding](/images/blog/laws-of-software-development/parkinsons-law.png)

#### Fazit

Wenn einem diese Gesetze und Prinzipien geläufig sind, wird man in der Praxis immer wieder auf sie stoßen. Sie bieten nicht nur Einsichten, sondern auch bewährte Leitfäden für erfolgreiche Projekte. Ob Reduktion der Komplexität, kluge Entscheidungen oder Fokussierung auf das Wesentliche – diese Regeln können als Anhaltspunkte dienen.

Trotz ihrer scheinbaren Strenge sollten wir im Hinterkopf behalten, dass ihre Anwendung oft flexibel ist. Ob und wie sehr man sich an diese Regeln hält, hängt von der jeweiligen Situation ab.

Fakt ist, diese Prinzipien sind ausgezeichnete Orientierungshilfen. Nutzen wir die Weisheiten, für unsere Softwareprojekte und heben diese auf das nächste Level – Code für Code.


Von Murphy bis Knuth: Die Gebote der Softwareentwicklung


Das Windows-Terminal bietet eine deutlich verbesserte Kommandozeile in Windows 10 und 11.
Es ist vollgepackt mit nützlichen Funktionen wie Tabs, Bereichen, Themes und Tastenkombinationen
sowie vollständiger Unterstützung für verschiedene Umgebungen wie PowerShell, Eingabeaufforderung
und Windows Subsystem für Linux.

In diesem Artikel beschreibe ich einige Möglichkeiten, wie das Terminal an deine Bedürfnisse angepasst
werden kann, und gebe ein paar Tipps und Tricks preis, damit deine Arbeit in der Kommandozeile reibungslos
und produktiv verläuft.

### Windows Terminal Features

Auf den ersten Blick sieht das Windows Terminal ziemlich einfach aus, aber es gibt einige Funktionen,
die es von der Standard Windows-Befehlszeile unterscheidet:

- Vollbildmodus
- Tab-Basierte Benutzeroberfläche
- Shortcut Tastenkombinationen
- Zoom mit der Maus (STRG + Mausrad)
- Unicode und UTF-8 Zeichenunterstützung erlaubt die Verwendung von Emojis 👩‍💻🔥👍
- Benutzerdefinierte Themes und Stile können erstellt werden
- Unterstützung für Windows Subsystem für Linux (WSL), SSH, PowerShell, Command Prompt, und Azure Cloud Shell

### Windows Terminal installieren

Leider liefert Microsoft das Windows Terminal nicht standardmäßig in Windows aus. Deshalb muss das Terminal entweder
über den [Microsoft App Store](https://aka.ms/terminal), [Github](https://github.com/microsoft/terminal/releases)
oder einen Package Manager (z.B.: winget, chocolatey, scoop) installiert werden.

### Windows Terminal konfigurieren

Nach der Installation kann das Terminal über mehrere Wege geöffnet werden:

- Über das Startmenü “Terminal” suchen
- WIN+R drücken und wt eingeben
- In Windows Explorer auf einem Ordner, oder in einem Leerbereich rechtsklicken und “In Terminal öffnen” auswählen
- In Windows Explorer in der Adressleiste wt eingeben
- Windows 11: WIN+X drücken und Terminal öffnen

Um die Einstellungen anzupassen wähle "Einstellungen" im Dropdown Menü oder drücke CTRL+,. Hier hast du die Möglichkeit
dein Terminal bis ins kleinste Detail zu konfigurieren. Es können verschiedene Profile für jede Shell angelegt werden
in denen Icons, Schriftart und Farben definiert werden. Das beste am Windows Terminal ist aber das die Konfiguration
im JSON Format gespeichert wird. Somit können Konfigurationen untereinander geteilt werden oder auf einen anderen PC übertragen werden.

Um das ganze noch visuell aufzupeppen empfehle ich die Installation von [Oh My Posh](https://ohmyposh.dev/).
Mit Oh My Posh liefert bessere Theme Funktionen mit denen beispielsweise der aktuellen Git status direkt im Terminal angezeigt werden kann.

Microsoft liefert hier ein Tutorial mit der die Installation ganz leicht klappt:

[Windows Terminal Custom Prompt Setup](https://learn.microsoft.com/en-us/windows/terminal/tutorials/custom-prompt-setup)

Ebenfalls zu empfehlen ist der Blog Post von Scott Hanselman:

[My Ultimate PowerShell prompt with Oh My Posh and the Windows Terminal](https://www.hanselman.com/blog/my-ultimate-powershell-prompt-with-oh-my-posh-and-the-windows-terminal)

![Windows Terminal konfiguriert mit Oh My Posh](/images/blog/windows-terminal/terminal-1.png)

### Bonus: Git Shortcuts

Um die tägliche Arbeit mit Git zu erleichtern habe ich mir noch einige PowerShell Alias erstellt.
Ein Alias unter PowerShell ist ein Synonym für einen PowerShell Befehl.
Um PowerShell Alias zu erstellen, öffne dein PowerShell Profil mit diesem Befehl:

```powershell[class="line-numbers"]
notepad $PROFILE
```

Um nicht immer die Befehle in der Konsole eintippen zu müssen und Typos entgegenzuwirken,
habe ich für jeden dieser Git Befehle PowerShell Alias erstellt:

```powershell[class="line-numbers"]
# Git Alias
# git status -> gco
function Get-GitStatus { & git status $args }
New-Alias -Name gst -Value Get-GitStatus

# git commit -> gco
function Set-GitCommit { & git commit -am $args }
New-Alias -Name gco -Value Set-GitCommit

# git checkout -> go
function Set-GitCheckout { & git checkout $args }
New-Alias -Name go -Value Set-GitCheckout

# git add -> ga
function Set-GitAdd { & git add $args }
New-Alias -Name ga -Value Set-GitAdd

# git pull -> pull
function Set-GitPull { & git pull }
New-Alias -Name pull -Value Set-GitPull

# git push -> push
function Set-GitPush { & git push }
New-Alias -Name push -Value Set-GitPush

# git add .
# git commit $args
# git push
# -> push-all commit message
function Set-GitSync { & ga . && gco $args && push}
New-Alias -Name push-all -Value Set-GitSync
```

Mit diesem Setup kann nun ganz leicht auf einen neuen Branch mit dem Befehl `go "branch-name"`
gewechselt werden. Zusätzlich gibt es einen `push-all` Alias mit dem es möglich ist alle aktuellen Änderungen
in das zentrale Repository zu pushen:

```powershell[class="line-numbers"]
push-all <commit-message>
```

### Fazit

Mit dem Windows-Terminal steht den Benutzern eine leistungsstarke und anpassbare Umgebung zur Verfügung,
um ihre Kommandozeilenarbeit zu verbessern. Egal, ob du ein Entwickler, Systemadministrator oder einfach
ein begeisterter Benutzer bist, das Terminal bietet die Werkzeuge, um effizienter zu arbeiten und Aufgaben
schneller zu erledigen. Wenn du noch nicht das volle Potenzial des Windows-Terminals ausgeschöpft hast,
solltest du definitiv die vorgestellten Tipps und Tricks ausprobieren, um das Beste herauszuholen.


Windows Terminal für Entwickler


Man stelle sich folgendes Szenario vor: Ein intensives Softwareprojekt wird endlich abgeschlossen, der Go-Live verläuft reibungslos und die Projektmitglieder erholen sich tagelang von der wohlverdienten Projektabschluss-Party. Also alles im grünen Bereich - bis dann ein paar Wochen später ein grober Fehler in der Applikation gefunden wird. Der Albtraum von allen Stakeholdern.

Wenn ein Fehler erst zu diesem späten Zeitpunkt gefunden wird, dann kostet die Behebung beispielsweise - jetzt mal ganz einfach gesagt fürs Verständnis - 100 Euro. Zu diesen 100 Euro zählen dann nicht nur die Kosten für die Behebung des Fehlers, sondern auch die Unzufriedenheit und mögliche Rufschädigung des Unternehmens. Hätte man den Fehler früher entdeckt - beispielsweise bei einem Sprint-Review - hätte die Behebung nur 10 Euro gekostet. Und hätte man diesen Fehler schon während der Entwicklung entdeckt? Dann hätten sich die Kosten für die Behebung wohl nur auf einen einzigen Euro belaufen, und es hätte keine potenziell unzufriedene Stakeholder, Rufschädigungen oder andere ärgerliche Folgen gegeben.

Dies ist die sogenannte “Rule of Ten” oder “1/10/100” Regel: Fehler sind mit jedem abgeschlossenen Produktlebenszyklus zehnmal teurer zu beheben. Dass an dieser Regel etwas dran ist - das mussten ehrlicherweise auch wir in der Vergangenheit schon erfahren. Doch wie verhindern wir das heute?

![Die Kosten pro Fehler explodieren exponentiell nach oben, wenn der Fehler in einer späteren Phase des Projekts gefunden wird.](/images/blog/rule-of-ten/rule-of-ten-graph.png 'Die Kosten pro Fehler explodieren exponentiell nach oben, wenn der Fehler in einer späteren Phase des Projekts gefunden wird.')

Wir haben nicht einfach aufgehört, Fehler zu machen: Erstens macht jeder Fehler. Zweitens sind sie nicht absichtlich und deshalb kann man sie auch nicht einfach so abstellen. Drittens lernt man mit dem richtigen Umgang von ihnen, weshalb Fehler nicht immer etwas Schlechtes sind. Deshalb geht es darum, so schnell wie möglich Fehler zu finden und zu korrigieren. Und zwar, bevor man in den nächsten Zyklus oder Sprint rutscht und sich die Behebungskosten verzehnfachen; Stichwort Prävention. Dies erreichen wir durch kompromisslose Qualitätsstandards und strenges Qualitätsmanagement.

Diese Standards reichen von Technologiewahl und DevOps bis zu Workflows und Codequalität. Beispielsweise wird unser Code immer vollautomatisch vom Tool [Sonar](https://www.sonarsource.com/) analysiert: Ist der Code für unsere Standards zu komplex und muss daher vereinfacht werden? Oder gibt es irgendwelche Sicherheitslücken oder Bugs? Anschließend muss noch ein weiteres Teammitglied den Code kontrollieren und freigeben, und erst dann landet er auch wirklich im finalen Projekt. Zusätzlich verwenden wir auch Unit-Tests, wodurch wir die gewünschte Funktion der Komponenten gewährleisten. Mehr zu unseren Qualitätsstandards und unserer Arbeitsweise findest du übrigens [hier](https://fortix.io/the-way-we-do).

Als [“Your partner in crime”](https://www.linkedin.com/posts/fortixio_your-partner-in-crime-activity-7036286285207986176-hX3f) setzen wir auf eine langfristige Zusammenarbeit. Und wie die “Rule of Ten” schön veranschaulicht, profitieren von unserer Qualität langfristig nicht nur die Geldbörsen und das Image unserer Kunden, sondern auch die Kunden von unseren Kunden. Beispiele hierfür sind unsere eindrucksvollen Projekte mit [ZIMA](https://fortix.io/case-study/zima) oder [amKumma](https://fortix.io/case-study/amkumma), die wir nach diesen beschriebenen Standards umgesetzt haben - und auch immer noch umgesetzt werden.


Rule of Ten: Darum ist Prävention wichtiger als Revision


### Wer bin ich überhaupt?

Wie erwähnt ist mein Name Tobias Hämmerle und ich studiere derzeit in Innsbruck am MCI. Dort habe ich gerade mein 2. Semester im Studienzweig Management, Communication & IT beendet. Ursprünglich komme und wohne ich im schönen Vorarlberg oder um genauer zu sein Lustenau.

### Wieso denn Fortix?

Es wurde mir schnell klar, dass Fortix für mich die richtige Option ist. Die Gründe dafür sind:

- der Aufgabenbereich der Firma: Schon in der HTL und nun auch teilweise im Studium habe ich mit Softwareentwicklung, speziell mit Webseiten, zu tun. Seither habe ich bemerkt, dass ein gewisses Interesse dafür vorhanden ist.
- Weiters ist das Büro in Dornbirn als (autoloser) Student von Lustenau aus mit Öffis sehr gut erreichbar.
- Der wahrscheinlich ausschlaggebendste Punkt war Martin Hämmerle, mein Cousin und zugleich Geschäftsführer von Fortix. Es führte fast kein Weg daran vorbei ihm zumindest in den Ferien etwas unter die Arme zu greifen.

### Was hatte ich zu tun?

Mein Aufgabenbereich bzw. mein Mitspracherecht, war tatsächlich größer als gedacht. Grundlegend war die Aufgabe den Webauftritt von Fortix neu zu gestalten. Das Design war zu 95% schon festgelegt und ich sollte das ganze nur noch in der Sprache des Webs umsetzen. Betonung liegt hier jedoch auf 95 und nicht 100%, denn dadurch war noch nicht alles in Stein gemeißelt.

Das wiederum bedeutete, dass ich meine Meinung und Designvorschläge ebenfalls miteinfließen lassen konnte. Somit hatte ich nicht nur wie ursprünglich geplant Codezeilen zu schreiben, sondern ich konnte auch meiner kreativen Seite freien Lauf lassen.

### Die Highlights

Highlights gibt’s einige die ich hier gerne kurz anführen möchte. So ist grundlegende die gemütliche Atmosphäre definitiv erwähnenswert und hat mir persönlich geholfen ohne Stress und dadurch auch produktiver und konzentrierter zu arbeiten.

Weiters haben alle Mitarbeiter einen guten Humor, was zum einen oder anderen Lacher führte und gute Erinnerungen hinterlässt. Für Aufregen und Ablenkung führte bei mir vor allem Cooper. Nein kein direkter Mitarbeiter, sondern „nur“ der Hund von Pius. So wurde ich beim Arbeiten das ein oder andere Mal von einer liebevollen Hundenase angestupst oder so lange von zwei braunen Knopfaugen beobachtet, bis ich meine Aufmerksamkeit auf sie richtete. Dann gab es für die nächsten paar Minuten jedoch kein Entkommen mehr. Cooper lässt sich nur durch eine große und lange Streicheleinheit oder durch Sessions mit dem Hundespielzeug zufriedenstellen.

Das Beste kommt zum Schluss und im Falle Fortix sind das definitiv die legendären Tischfußballspiele. Diese finden vor allem zur Mittagszeit oder als Auflockerung am Nachmittag statt. Das Ganze kann bei gutem Stellungsspiel so weit führen, dass gegen Ende nicht nur die Nerven blank liegen, sondern auch ein paar Schweißperlen zu sehen sind. Meine Entwicklung vom leicht Fortgeschrittenen Anfänger im Tischfußball zum Amateur macht sich inzwischen definitiv auf dem Spielfeld bemerkbar und diese Fähigkeit werde ich aus meinem Praktikum bestimmt mitnehmen!

### Das Fazit

Abschließend kann ich sagen, dass ich definitiv noch nie so viel Spaß beim, aber vor allem an der Arbeit selbst hatte. Das Ganze hat mir sogar so gut gefallen, dass dies sicherlich nicht meine letzten Zeilen Code bei FORTIX waren. Also jedem der überlegt bei Fortix ein Praktikum oder ähnliches zu machen, dem kann ich das Ganze nur wärmsten empfehlen.


Mein bisher bester Ferialjob


Am 28. Mai überreichte Landesrat Marco Tittler den Innovationspreis 2021. Wir sind extrem stolz, denn die etablierte Auszeichnung bestätigt einerseits unsere Arbeit und gibt uns andererseits ein sehr gutes Gefühl für die Zukunft.

![](/images/fortix-team-innovationspreis-2021.jpg 'Innovationspreisträger 2021')

Das Siegerprojekt heißt „loja“. Bei loja handelt es sich um eine digitale Plattform für Händler und Gastronomen. loja verzeichnet inzwischen über 200 Einzelhändler, Restaurants, Bäckereien, Bars und Cafés, die aktiv mit Treuepunkten das neuartige Kundenbindungsinstrument nutzen.

### Neue Ausrichtung

loja selbst ist inzwischen ein eigenständiges Unternehmen, welches sich zu 100 % auf die bevorstehenden Aufgaben konzentrieren kann. FORTIX wird der Plattform als technischer Partner zur Verfügung stehen.

![](/images/fortix-marco-tittler-innovationspreis-2021.jpg 'Innovationspreisträger 2021')

Wir freuen uns sehr über die Auszeichnung und gratulieren den weiteren Gewinnern (mehr zum [Innovationspreis](https://vorarlberg.orf.at/stories/3105774/)) . Außerdem möchten wir uns bei allen Unterstützern bedanken, die uns auf unserem Weg unterstützen.

Bilder © Sams Foto

Weitere Links:

[orf.at](https://vorarlberg.orf.at/stories/3105774/)

[vn.at](https://www.vn.at/markt/2021/05/27/welche-vorarlberger-firmen-fuer-ihre-innovationen-ausgezeichnet-wurden.vn)

[vol.at](https://www.vol.at/innovationspreis-2021-sieben-unternehmen-ausgezeichnet/7003128)

[wirtschaftszeit.at](https://www.wirtschaftszeit.at/news/innovationspreis-2021-sieben-unternehmen-fuer-ihre-exzellenten-ideen-ausgezeichnet/)


Sieger Innovationspreis 2021


Bald feiere ich doppeltes Einjähriges: Ein Jahr als Junior Developer bei FORTIX und ein Jahr als Student in Innsbruck. Studieren wollte ich schon immer, bei FORTIX zu arbeiten – da bin ich irgendwie reingerutscht.

Deshalb möchte ich in diesem Blogeintrag mein letztes Jahr reflektieren: Wie ist es neben dem Studium zu arbeiten? Halte ich dies nach wie vor für einen genialen Schachzug oder empfinde ich den Mehrwert als zu gering? Und welche Rolle spielt dabei eigentlich FORTIX?

![Leon Bahl](/images/leon_bahl.jpg)

Zuerst einmal möchte ich folgendes klarstellen: Ich studiere nicht das, als was ich bei FORTIX angestellt bin. Statt Web- und Softwareentwicklung studiere ich Management, Communication und IT am [Management Center Innsbruck (MCI)](https://www.mci.edu/de/). Ich lerne also großteils verschiedene Aspekte über Bilanzierung und Buchhaltung, Kostenrechnung, Unternehmensrecht und so weiter. Klar, wie der Name des Studiums schon verrät, dreht sich trotzdem ein Teil des Studiums um IT. Dieser beschäftigt sich bislang mit allgemeinen Grundlagen und ist dafür da, dass man einen ersten Eindruck von unterschiedlichsten Technologien erhält: Wie funktioniert prinzipiell eine kleine Webseite mit HTML, CSS und JavaScript? Wann sollte man eher diese oder jene Datenbank verwenden? Was ist eine asymmetrische Verschlüsselung? Die explizite Anwendung steht also nicht unbedingt im Vordergrund. Dennoch bekommt man ein nicht zu unterschätzendes Grundgerüst, auf welchem man schlussendlich selbst detaillierteres Wissen aufbauen kann, je nachdem, welches Thema einen mehr interessiert.

### Wie ist der bisherige Fortschritt?

Für mich persönlich sind das alles bis jetzt entspannte Vorlesungen, da ich eigentlich alles schon Mal in der [HTL Dornbirn](https://www.htldornbirn.at/) und in verschiedenen Praktika gehört oder angewendet habe. Das bedeutet aber auch, dass ich das, was ich im Studium lerne, nicht unbedingt direkt anwenden kann. Doch das finde ich absolut nicht schlimm: Ich persönlich sehe das Studium eher als eine Art notwendiges Grundwissen, welches man benötigt, um in der wirtschaftlichen Welt mitspielen oder um sie zumindest verstehen zu können. Es ist daher spannend, wenn ich im Büro Stichwörter wie wirtschaftliche Kennzahlen oder ähnliches aufschnappe: Vor dem Studium hätte ich mir darunter nichts vorstellen können. Mittlerweile weiß ich haargenau, was gemeint ist.

### Arbeiten und gute Noten - ein Widerspruch?

Bei meinem Studium handelt es sich um ein Vollzeitstudium. Manchmal muss man also mit der Zeit jonglieren, damit man alles unterbringt: Lernen, arbeiten und auch das ein oder andere Bier muss natürlich unter einen Hut gebracht werden. Das funktioniert so weit ganz gut, aber ich profitiere auch davon, dass mir FORTIX an dieser Stelle entgegenkommt: Vor den Prüfungsphasen kann ich Überstunden aufbauen, in den Prüfungsphasen kann ich die Überstunden abbauen. Somit kann ich mich voll auf meine Klausuren konzentrieren. Daher leiden meine Noten nicht neben meiner Tätigkeit bei FORTIX und ich kann trotzdem noch Praxiserfahrung und ein feines, zusätzliches Taschengeld sammeln.

### Profit aus der Kombination

Man kann also sagen, dass ich das Studium und die Arbeit in gewisser Weise auf mich angepasst habe: Am MCI lerne ich die wirtschaftlichen Grundlagen, die ich, wie vorhin beschrieben, für mich persönlich als sehr wertvoll betrachte. Bei FORTIX kann ich mich bezüglich Entwicklung von Software und Anwendung von Projektmanagement praxisnah vollends austoben und persönlich weiterentwickeln. Außerdem bekomme ich viele Eindrücke in Bezug auf den Arbeitsalltag, das Knüpfen von Kontakten und habe die perfekte Abwechslung.

Wenn ich nun abschließend diese ganzen Gedanken und Eindrücke zusammenbringe, finde ich folgende Metapher ziemlich passend: Theorie ohne Praxis ist wie ein Pinsel ohne Farbe. Im Studium bekommt man das theoretische Wissen, den Pinsel. Aber nur mit dem theoretischen Wissen malt man halt doch keine Mona Lisa: Man benötigt zwingend auch die Praxis, in diesem Fall die Farbe. Denn ohne das perfekte Zusammenspiel des richtigen Pinsels und kräftigen Farben kann man kein strahlendes Kunstwerk malen.


Studium und Arbeit – Rückblick auf ein Jahr Student und Junior Developer


Kollegen und Bekannte erzählen mir, dass in ihren Unternehmen derzeit über die Maßnahme Home-Office nachgedacht wird. Aufgrund der Tätigkeiten wäre das in einigen Fällen auch sehr gut möglich. Man könnte die kommende Zeit — keiner weiß ja schlussendlich was uns genau erwartet — sicher überbrücken und das ohne, dass gesamte Unternehmen stillstehen. Allerdings scheitert es oft an der Infrastruktur. Das meist quer durch die Bank: Großunternehmen, kleine 5-Mann-Buden oder öffentliche Institute. Branchenunabhängig.

Meine persönliche Meinung ist deshalb folgendes: Wir sollten in Politik, Wirtschaft und Medien den Einsatz von plakativen Buzzwords wie beispielsweise High-Tech-Startups, Blockchain, Artificial Intelligence und Co. reduzieren. Versteht mich nicht falsch! Die Themen sind alle wichtig und zukunftsträchtig (vorausgesetzt man weiß wovon man spricht 😉). Allerdings sollte es zunächst unser Ziel sein eine flächendeckende, solide Basis zu erreichen.

![](/images/pexels-thisisengineering.jpg)

Über Tätigkeiten wie zeit- und ortsunabhängiger Zugriff auf arbeitsnotwendige Dokumente sollten wir im Jahr 2020 eigentlich nicht mehr diskutieren. Ein Buchhalter der täglich 8 Stunden am PC arbeitet, sollte ohne großen Aufwand, auch von zu Hause arbeiten können. Themen wie Berechtigung und Access stellen aufgrund der Vielzahl von Lösungen keine unüberwindbare Challenge mehr dar.

Ich gehe sogar noch einen Schritt weiter und behaupte, trotz Berücksichtigung von Faktoren wie Produktivität und etwaigen Kontrollverlust, dass ein modernes Unternehmen seinen Mit-arbeitern die Möglichkeit geben sollte, von zu Hause zu arbeiten. Vorausgesetzt es gibt eine klare Regelung, wie beispielsweise in vereinbarten Maßen (z.B. Freitag = Homeoffice, insofern keine Termine anstehen) oder bei Bedarf (ungünstiger Arzttermin, Tochter von Schule abholen, etc.). Die Vorteile überwiegen meiner Meinung nach den Nachteilen. Aber am besten ist, wenn sich jeder selbst eine Meinung davon bildet: Success-Stories, Warnungen und Pro-/Kontra-Listen zu dem Thema gibt es im Internet bereits genug.

![](/images/mac-dashboard.jpg)

Long story short: In Bezug auf die Digitalisierung müssen wir uns klare Gedanken machen. Derzeitige Maßnahmen scheinen, wie die unglückliche Situation zeigt, nicht zu fruchten. Natürlich ist jedes Unternehmen auch selbst in der Pflicht, sich zu informieren und weiterzuentwickeln. Allerdings kann ich verstehen, dass die ganze Debatte bezüglich digitaler Transformation mit der Zeit unübersichtlich und komplex erscheint. Wie heißt es so schön: _„Man kann vor lauter Bäumen den Wald nicht sehen“_. Deshalb denke ich, dass weniger mehr ist. Etwas weniger „Bullshit-Bingo“ und dafür konkrete Lösungen, welche auch umsetzbar sind und uns als Wirtschaftsstandort weiterbringen.

Aber wie können wir euch gezielt unter die Arme greifen? Vor allem für kleine Unternehmen haben wir in letzter Zeit verschiedene Szenarien ausgearbeitet und auch umgesetzt. Unser gemeinsames Ziel ist es, mit möglichst geringen technischen Aufwendungen und folglich auch geringen Kosten, eine Lösung für die Arbeit von zu Hause zu ermöglichen. Wir haben uns den Aspekt bezüglich Remotezugriff auf die firmeninterne Infrastruktur und vor allem die Kommunikation der nun verteilten Mitarbeiter mit Chat-Tools zu optimieren genauer unter die Lupe genommen. Bei Fragen zu einzelnen Tools, Erfahrungsberichten oder auch konkreter Hilfe bei der Umsetzung bitte einfach melden. Wir helfen gerne.
