CRN-Interview mit Dirk Walkowiak von C4B
»Die Messlatte ist der Kundennutzen«
Fortsetzung des Artikels von Teil 1
Open Source
CRN: Sind Open Source-Komponenten relevant für die Entwicklung neuer Software?
Walkowiak: Open Source-Software betont zumeist den technischen Aspekt. Basistechnologien wie Bibliotheken (Grafik, Security) oder komplette (Micro-)Services (Freeswitch, Asterisk, OpenFire) werden entwickelt und exemplarisch konfektioniert.
Die Nutzung solcher Technologien kann allerdings ein zweischneidiges Schwert sein. Weil die Eigenentwicklung entsprechender Projekte in den meisten Fällen viel zu teuer wäre, ist es sehr verlockend, Open Source-Komponenten zu verwenden. Dabei darf man aber nicht vergessen, dass man als Hersteller immer die volle Verantwortung für sein Produkt trägt. Wenn Fehler in der Open Source-Software zu Fehlern im Produkt führen, kann man sie nicht der Community anlasten, sondern muss selber dafür gerade stehen.
Auf der anderen Seite besteht die Chance, vom Engagement vieler hochqualifizierter Entwickler zu profitieren. Wir setzen in unserer Unified Communications-Software deswegen ausgewählte Open Source-Komponenten ein und fördern die Community im Gegenzug mit Spenden.
CRN: Muss ein Software-Entwickler heutzutage auf jeden Fall Javascript beherrschen?
Walkowiak: Wenn dem so wäre, dann müsste ich wohl mehr als die Hälfte meines Teams entlassen. Javascript ist „nur“ ein Werkzeug. Und das nehme ich her, wenn es die Aufgabe erfordert. Wenn ich zum Beispiel hardwarenahe Treiber entwickle, benutze ich dafür sicher kein Javascript.
Aber: Die meisten populären Softwareprodukte finden heute im Browser statt. In einer Welt also, in der „schon immer“ mit Javascript entwickelt wurde. Und es kommen ständig tolle, neue JS-Frameworks wie z.B. Angular dazu – neuerdings sogar mit strenger Typisierung (Angular 2 mit Typescript).
Auf der Serverseite wurde die Programmlogik bisher in Java, PHP & C# entwickelt. Eine hohe technische Anforderung an Web-Entwickler! Seitdem es aber auch auf dem Server performante Javascript-Laufzeitumgebungen (Node.js) gibt, kann ein Web-Entwickler in seiner gewohnten Umgebung auch die Serverlogik implementieren. Mehr noch: Er kann dieselbe Programmlogik (z.B. Validierungsroutinen) sowohl auf dem Client als auch auf dem Server einsetzen.
Wenn sich das auf breiter Front durchsetzt, dann entwickelt sich der Markt für Javascript-Entwickler tatsächlich rosig. Und es spricht einiges dafür: Immer mehr Anwendungen werden komplett in die Cloud verlagert. Und auch das klassische Betriebssystem wird zunehmend durch „das Web“ ersetzt. Dort speichere ich meine Daten, dort laufen meine Applikationen, dort vernetzen sich immer mehr Bestandteile meines täglichen Lebens zum IoT. Und Javascript hat das Potential, der universelle Klebstoff dafür zu sein.
CRN: Wird das klassische Wasserfallmodell dem Tempo der Digitalisierung noch gerecht?
Überbordende Effizienz war tatsächlich noch nie die Stärke des Wasserfallmodells. Weil man Fehler in der Planungsphase später praktisch nicht mehr beheben kann, wird zu Beginn ein unglaublicher Aufwand in die Beschreibung investiert. Und so geht schmerzlich viel Zeit ins Land, ohne dass auch nur eine Zeile Code geschrieben wurde. Im besten Fall wird am Ende das entwickelt, was man anfangs geplant hat. Aber mit einiger Wahrscheinlichkeit nicht das, was am Ende jemandem nützt.
Die Wasserfall-Verfechter betonen den Vorteil einer weitblickenden Planung (z.B. bei Architektur, API’s oder Schnittstellen). Der Trugschluss liegt meiner Meinung nach darin, dass man viel zu viel Zeit in das Design einer vermeintlich „perfekten“ Architektur investiert. Aber in einer Zeit, in der sich die technischen Möglichkeiten und Anforderungen immer schneller ändern, ist eine Architektur dann perfekt, wenn sie leicht auf Veränderungen reagieren kann.
- »Die Messlatte ist der Kundennutzen«
- Open Source
Lesen Sie mehr zum Thema
