Michaels Blog

Wie man auf heise.de lesen kann, kam es wieder vor, dass Windows Update trotz entsprechender Einstellung (nur manuelle Updates) automatisch Updates eingespielt hat. Nachdem Microsoft offenbar davon ausgegangen ist, dass ein Microsoft-fremdes Programm dieses Verhalten provoziert hat.

Inzwischen verdichten sich Hinweise, dass Windows OneCare und/oder das aktuelle Microsoft Office Schuld an dem neuerlichen AU-Problem sein könnten.

Es wird lustiger:

Inzwischen verdichten sich Hinweise, dass Windows OneCare und/oder das aktuelle Microsoft Office Schuld an dem neuerlichen AU-Problem sein könnten.

Es ist schon leicht befremdlich, wenn man das Gefühl hat, dass a) jedes Programm das Updateverhalten beeinflussen kann und b) man bei Microsoft selbst offenbar im Dunklen tappt.

Es ist sicherlich richtig, dass der Anwender oft nicht einschätzen kann, was er da über Windows Update angeboten bekommt. Aber es ist in meinen Augen sinnvoller, ihn drüber zu informieren und ihm die Wahl zu überlassen. Es ist ja nicht so, dass man keine Möglichkeit hat, dem Anwender die Dringlichkeit eines Updates kenntlich zu machen.

Jemand der das installieren von Updates manuell beeinflussen möchte, muss durch dieses Systemverhalten zwangläufig zu dem Schluss kommen, dass er seinen eigenen PC nicht mehr unter Kontrolle hat. Das Vertrauen in das System hängt dann davon ab, wie sehr man der Kontrollinstanz traut.

Daher stellt sich nur eine Frage: Vertraust Du Microsoft?

Mashups sind SOA(Service Oriented Architecture)s. Das der Browser die Plattform, in dem Fall der ESB (Enterprise Service Bus) ist, ist eher Vor- als Nachteil. Wobei man eher von „Service Bus“ reden sollte, denn das „Enterprise“ bezieht sich ja nicht auf das Geschäft, sondern auf die Technologie. Und die ist wesentlich schlanker als etablierte ESB Implementierungen.

Betrachtet man die Softwareentwicklung sind klar zwei Trends zu erkennen.

Auf der einen Seite entstehen Anwendungen durch die Komposition von verschiedensten Services durch den Nutzer. Dabei kann dieser Nutzer diese Anwendungen nicht nur selbst benutzen, sondern sie auch anderen zur Verfügung stellen und sogar sein Geschäftsmodell darauf gründen.

Auf der anderen Seite werden, wenn man verschiedensten Printmedien und Consultants glauben darf, Systeme mit einer ähnlichen Architektur aber mit weit größerem Aufwand realisiert. Manchmal könnte man meinen, dass die Erfahrungen aus der Fehlentwicklung im Bereich EJB (Enterprise Java Beans) zu weit zurück liegen, um aktuelle Entwicklungen kritisch zu hinterfragen.

Dabei ist es sehr unwahrscheinlich, dass ein Architekturmodell für zwei verschiedene Probleme ähnlich aussieht. Das Bestreben jedes Softwareentwicklers sollte darin liegen, weniger Code zu schreiben und mehr Zeit mit Nachdenken zu verbringen. Aber genau da sehe ich ein Problem, denn aktuelle Architekturen mutieren zu Monstern, denen ein kleines „Hallo Welt“ mit unverhältnismäßigem Aufwand zu entlocken ist.

Sind Softwareentwickler ähnlich veranlagt wie Lemminge? Man muss es vermuten. Auf jeden Fall haben sie einen kleinen goldenen Hammer dabei.

Es ist nur eine Frage der Zeit, bis es so einfach ist, sich mit Meshups eine Anwendung zusammen zu bauen, dass man zur Umsetzung einer Geschäftsidee keine Zeile Code mehr schreiben muss, sondern sich aus dem reichhaltigen Angebot an Services bedient und einfach über ein benutzerfreundliches Interface zusammenstellt.

Everyone is a Software Architect.

Als ich mit Softwareentwicklung angefangen habe, gab es keine IDE oder Compiler. Meine ersten Programme schrieb ich in Basic und danach mit Basic und Maschienencode (toll. Zahlen auswendig lernen).

Irgendwann gab es dann C-Compiler und Programmieren war spannend und abenteuerlich. Mit C++ wurde es dann das erste mal kreativ und Code wurde zur Kunst. Ein Programm konnte man auf verschiedenen Wegen realisieren. Einige meiner Programme waren recht plump und andere waren unglaublich elegant (zumindest erschien es mir damals so).

Seit dieser Zeit ist Programmieren für mich ein Ausdruck von unglaublicher Kreativität. Dabei ging es manchmal um Geschwindigkeit, manchmal darum, wie man mit wenig Code sehr viel erreichen kann, manchmal auch darum, etwas anders als erwartet zu benutzen.

Reale Probleme verlangen oft nach bodenständigen Lösungen. Im Laufe des Lebens wird man immer wieder dazu gezwungen, Programme zu schreiben die Probleme lösen, die nicht besonders spannend oder elegant sind (weil die Probleme zum Teil ja schon Designfehler haben).

Immer wieder wird man mit grundlegenden Anforderungen konfrontiert, die man dann das erste mal selbst lösen muss, obwohl eigentlich alle anderen genau die gleiche Anforderung haben müssten. Besonders durch OpenSource-Projekte wurden viele grundlegenden Probleme gelöst und man findet heut zu fast jedem Problem eine passende Lösung, die man nur noch einbauen muss.

Die letzte Stufe der Entwicklung wird so langsam eingeläutet. Denn nach dem nun alle Bestandteile einer klassischen Businessanwendung vorhanden sind, beschränkt sich die Softwareentwicklung auf das Zusammenstecken und Verkleben. Das ganze nennt man „Business On Demand“ und wird zunehmend als Softwareplattform angeboten. Jetzt ist auch einem vollkommen unkreativer Geist in der Lage, eine klassische Anwendung zusammenzubauen. Das kann man vermutlich sogar bis zur Fließbandarbeit weitertreiben.

Auf der einen Seite ist es ja durchaus beruhigend, wenn wir die Herausforderungen der letzten Jahre endlich gemeistert haben, auf der anderen Seite müsste man sich gerade jetzt damit beschäftigen, über das bestehende hinauszuschauen, um eine der letzten großen Herausforderungen im Bereich Softwareentwicklung zu meistern.

Die letzte große Herausforderung – Was ist das?

Zumindest an dieser Stelle ist die Antwort ungewohnt einfach. Doch besser geht es in Frageform:

• Wieso muss ich mich daran gewöhnen, wie der PC arbeitet?
• Wieso funktioniert das Programm nicht, wie ich es erwarten würde?
• Warum brauch ich unterschiedliche Geräte für unterschiedliche Aufgaben?
• Warum kann ich meine Daten nicht auf all meinen Geräten bearbeiten?

Softwareentwickler sind keine Nutzer. Aber Softwareentwickler nehmen sich selbst oft als Maßstab. Dass führt zu Produkten, die vermutlich nur „ein“ (im schlimmsten Fall „der“) Softwareentwickler bedienen kann.

Die Möglichkeit, dass der Nutzer die Funktionen, die er braucht beliebig zusammenstellen und vernetzen kann, wird zu viel interessanteren Anwendungen führen, als man sich das heute vielleicht vorstellen mag.

Aber auf alle Fälle sollte es dazu führen, dass das Geräte genau das machen, was ich möchte. Markenzeichen: Funktioniert wie erwartet.

Ich bin relativ vergesslich. Wobei sich das meist schon eher auf Termine (auch Geburtstage) und Namen bezieht. Was ich mir dafür relativ gut merken kann, ist der Weg auf dem ich eine Information, der ich schon begegnet bin, wiederfinde.

Wenn es um die Softwareentwicklung geht, muss ich feststellen, dass es für mich viel einfacher ist, die Informationen nicht in einem Buch zu dem Thema sondern direkt in Programmcode zu finden. Es geht einfach schneller, solange ich weiß, dass ich dazu schon mal was gemacht habe. Ein weiterer Vorteil ist, dass ich dabei sehe, wie ich dieses Thema (evtl. unter Anwendung einer Bibliothek) angegangen bin. Das geht soweit, dass ich Bücher immer nur dann lese, wenn ich etwas aus dem Buch noch nicht benutzt habe.

Dabei fallen mir zwei Fragen ein: Warum gibt es die Bücher nicht online, so dass man einen Link auf die Seite oder das Kapitel setzen kann? Würde es Sinn machen, in einem Buch so mitten drin Platz für Notizen zu lassen (nicht nur am Ende (habe ich da auch noch nie benutzt)).

Ich bin mir nicht ganz sicher, was das alles so bedeutet. Auf der einen Seite bin ich mir sicher, dass für die Dokumentation von Programmcode nur der Code selbst aussagekräftig genug sein kann, so dass eine zusätzliche (und manuell zu pflegende) Dokumentation überflüssig werden kann. Auf der anderen Seite glaube ich, dass es zu jedem Fachbuch ein kurze Zusammenfassung geben sollte.

Auch wenn es schon sehr viele Dokumentationen (unterschiedlichster Qualität) im Netz gibt, macht es vielleicht Sinn, ein Developer-Wiki aufzusetzen, dass ähnlich wie Wikipedia aufgebaut ist und sich nur mit Softwareentwicklung beschäftigt.

Wie ich mit dem Erscheinen von Adobe Apollo bereits erwähnte, verändert sich das Web sehr stark in Richtung Desktop. Auf dem Google Developer Day zeigte dann in einer Liveübertragung aus Mountain View Adobe auf einer Google Veranstaltung nocheinmal die Möglichkeiten von Apollo. Wer sich fragt, wieso Adobe auf dieser Veranstaltung aufgetreten ist, hat dem Punkt verpasst, an dem Google Gears vorgestellt wurde.

Interessant und sicher für den einen oder anderen etwas erschreckend ist die Tatsache, dass beim aktuellen Trend aus Webanwendungen desktopintegrierte Anwendungen zu schaffen Adobe und Google zusammenarbeiten und das ganze dann auch noch unter Open Source stellen.

Nutzer nutzen Dinge. So wird es stark davon abhängen, wie gut solche Anwendungen laufen und welchen Mehrwert sie bieten. Aber es ist nicht davon auszugehen, dass Nutzer aus idellen oder kulturellen Gründen solche Anwendungen ablehnen werden, denn dann würde man diese Menschengruppe anders nennen. Es hängt also alles an einer guten Lösung, einem guten Produkt.

Das bedeutet, dass das Web sich verändern wird und der Desktop zwar nicht überflüssig werden wird, in der Wahrnehmung aber eher in den Hintergrund tritt. Auch das Betriebssystem wird recht schnell irrelevant und die klassische Softwareverteilung durch webbasierte Anwendungssoftware in größerem Maße unnötig. Wenn ich mich recht erinnere hatte damals Netscape die ersten Ideen, wie man auf dem Desktop viel interessantere Sachen darstellen könnte, als so öde Icons. Das war damals m$ Grund genug, das nicht zu mögen. Was damals noch funktionierte wird mit diesem Gegenspieler und den technischen Möglichkeiten nicht mehr funktionieren. Mit dem Internet als Plattform ist es jedem möglich an einem globalen Wettbewerb um die guten und besten Lösungen teilzunehmen. Und gerade kleinere agile Entwicklungen werden davon profitieren, sofern sie erfolgreich die neuen Technologien adaptieren und das Produkt herausragt.

Everyone is a software architect. Just develop it.