Berg Software blickt auf 30 Jahre Softwaretechnologie zurück

Sie wissen ja, dass ein Hundejahr etwa fünf Menschenjahren entspricht? So ist es auch in der Softwarebranche: Die hohe Innovationsgeschwindigkeit in Verbindung mit spannenden Kundenprojekten führt dazu, dass sich 30 Jahre Softwareentwicklung wie 150 Jahre anfühlen. Bedeutet das, dass wir alt sind? Nein, nur erfahren und wie immer bereit, mit jeder neuen Technologie mitzuhalten.

Aber was macht eigentlich Erfahrung aus?

Auf der einen Seite geht es dabei um das richtige Team: eine Mischung aus langjährigen Softwareentwicklern und Softwareentwicklerinnen, die mit beiden Beinen fest auf dem Boden stehen und immer auf der Suche nach den besten Lösungen für die Projekte ihrer Kunden sind, sowie aus energiegeladenen Programmierern und Programmiererinnen, die mit leuchtenden Augen die Welt verändern wollen.

Auf der anderen Seite findet sich die Erfahrung in der Art und Weise, wie wir arbeiten: Das Anpassen unserer Denkweise, sowie unserer Prozesse und Methoden an neue Gegebenheiten ist dabei ein wesentlicher Aspekt.

Um all dies zu verdeutlichen, lassen Sie uns einen Blick auf die (nicht ganz vollständige) Liste der Softwaretechnologien werfen, die wir in den letzten 30 Jahren eingesetzt haben. Anschließend wollen wir gemeinsam betrachten, wie sich unsere Arbeit im Laufe der Jahre verändert hat.

30 Jahre Softwaretechnologie

Zunächst einmal: In den letzten 30 Jahren haben wir mit vielen Softwaretechnologien gearbeitet und uns über sie alle – mit Ausnahme der jüngsten – hinausentwickelt. Ja, 30 Jahre sind im Bereich der Softwareentwicklung bereits eine lange Geschichte, doch noch viel wichtiger ist, dass sich Berg Software ständig weiterentwickelt, ganz gleich, welche Herausforderungen auf uns zukommen:

• 1994-1995 programmierten wir mit FoxPro, DOS und Windows.
• 1996-1997(ungefähr): Unix, C, VisualC++, ObjectPascal, Delphi, Lotus Notes, Domino Server, Catia
• 1998: Visual Basic
• um das Jahr 2000 herum: HTML, Java und ASP für Webanwendungen
• 2000-2012: ein Boom von Frameworks, die wir nach und nach einsetzten, z. B:
  • neue Java-Frameworks (z. B. von Servlets, Swing, JSP, JSF, RCP, bis zu Struts, Hibernate, Spring)
  • neue .NET-Frameworks (z. B. C#, VB, ASP, Windows Forms, ASP.NET, MVC, WCF, Entity Framework, WPF usw.)
• 2007: erste BI-Arbeiten
  • SQL Server+
  • ETL (DTS wurde zu MSIS/Multi-Source Service Integration, jetzt SSIS/SQL Server Integration Services)
  • kustomisiert entwickelte Datenintegrationsengine
  • multidimensionale Datenbanken (zunächst Analysis Services, dann eine von Berg Software entwickelte Engine)
  • kustomisierte Entwicklung von Datenvisualisierungs- und Analysetools
• 2007-2008: JQuery
• ab 2012: J2EE, Spring, SAP-Technologien (SAP Fiori, SAP UI5, OData, ABAP, NetWeaver, HANA)
• ab 2012: Virtualisierung (Cloud-Lösungen über AWS, Microsoft Azure, OTC/Open Telekom Cloud)
• ab 2012-2013: Bootstrap, GWT
• 2015-2020: verschiedene JavaScript-/TypeScript-Frameworks für moderne Webanwendungen: von AngularJS bis Angular 12 und React
• 2018: DevOps-Tools (Docker, CI/CD, Kubernetes, Terraform, Ansible, Istio, Jenkins, GitLab usw.)
• ebenfalls 2018: BigData (Elastic Search, ClickHouse, Kafka, Spark, MongoDB)
• derzeit: beobachten wir den anhaltenden Trend zu Frameworks, die spezifische Anforderungen lösen (z. B. mehrere UI-Frameworks)

Ist Ihnen schon ganz schwindlig geworden? Lassen Sie uns wieder festen Boden unter den Füßen bekommen, indem wir uns ansehen, wie diese Technologien die Art und Weise verändert haben, in der wir Softwareentwicklung betreiben.

30 Jahre Erfahrung (in der Softwareentwicklung)

Als wir unsere älteren erfahreneren Kolleginnen und Kollegen fragten: „Wie hat sich das Geschäft der Softwareentwicklung in den letzten 30 Jahren verändert?“, bekamen wir zu hören: „Gar nicht! Es ist immer noch Softwareentwicklung.“ Doch dann fingen sie an zu schwärmen: „Oh! Die Dinge sind nach dem Internet-Boom ganz anders als in den 1990er Jahren.“

Die Arbeit mit den Kunden: persönlich oder remote

Ein Projekt ist immer noch ein Projekt. Das Verstehen der Bedürfnisse der Kunden ist immer noch der Ausgangspunkt. Qualitativ hochwertige Arbeit an spannenden Projekten zu leisten und auf das Ergebnis stolz zu sein, ist nach wie vor der wichtigste Antrieb für jede/n Softwareentwickler/in.

Aber die webbasierte Kommunikation macht das Leben aller Beteiligten viel einfacher. Zumindest werden dadurch die Geschäftsreisen zwischen den Kunden und dem Softwareentwicklungsunternehmen reduziert. Für Berg Software waren die Veränderungen einschneidend. Man bedenke nur, dass vor 2000 (vor dem EU-Beitritt Rumäniens) jede Reise zum Firmensitz eines Kunden 16-20 (-28!) Stunden Fahrtzeit für zwei- bis drei Tage voller Besprechungen erforderte.

Heutzutage haben wir wahrscheinlich genau die richtige Mischung: persönlich für die seltenen Situationen, in denen wir den persönlichen Kontakt brauchen, und remote für die reguläre, tägliche Arbeit.

Methoden: Wasserfall- vs. Agile-Ansatz

Eine weitere große Veränderung ist der Übergang von der klassischen/Wasserfall-Methode zur agilen Methode, was auf die Entwicklung der Denkweise (und weniger der Technologie) zurückzuführen ist.

Bei der Wasserfall-Methode sind Projekte (fast immer) überspezifiziert. Jedes einzelne Fenster und jede Schaltfläche eines Softwareprodukts im Detail zu beschreiben, kann zu monatelangen Verzögerungen, 500-seitigen Anhängen und künstlich erhöhten Preisen führen. Am Ende gibt es natürlich keine „perfekte Spezifikation“, so dass man höchstwahrscheinlich mit weiteren Entwicklungen/Korrekturen/Verzögerungen/Kosten rechnen kann.

Hier kommt die agile Methode ins Spiel, bei der die Software die Bedürfnisse des Kunden innerhalb eines festen Budgets erfüllen muss. Die Software-Entwicklung durchläuft kürzere Iterationen (z. B. jeweils 2-3 Wochen), in denen bestimmte Problemstellungen gelöst werden. Am Ende einer jeden Iteration muss alles perfekt funktionieren. Dann wird auf der Grundlage der festgelegten Prioritäten zur nächsten Iteration übergegangen. Auf diese Weise schreitet das Projekt in die richtige Richtung voran, so dass der Kunde am Ende wirklich *bekommt*, was er braucht. Wenn sich überhaupt etwas ändert, dann sind es die kleinen Dinge. Etwa 90 % der Anforderungen werden im Rahmen des zugewiesenen Budgets umgesetzt (100 % der „Must-haves“), und das Softwareprodukt wird wie vorgesehen funktionieren.

(Ja, wir sind uns darüber im Klaren, dass der agile Ansatz ebenso viel kosten kann – aber das ist eher bei Projekten der Fall, bei denen sich die Dinge *sehr stark* ändern).

＿

Wenn wir eine Zusammenfassung unserer 30-jährigen Erfahrung in der Softwareentwicklung geben müssten, dann würde diese lauten: „Sagen Sie uns, was Sie wünschen, und wir werden Ihnen höchstwahrscheinlich ein ausgezeichnetes Ergebnis liefern.“ Und das Beste daran ist, dass wir über die richtigen Fähigkeiten (und Verfahren) verfügen, um alles zu meistern, was in Zukunft auf uns zukommt.