Michaels Blog

Wer Software entwickelt, Programme schreibt kennt das Problem. Man ist fast fertig und es läuft alles. Man ist weit unter der geschätzten Zeit geblieben. Das kann man dem Auftraggeber nicht zumuten.

Da müssen Fehler her. Und nicht nur einfach so Fehler, sondern die ganze Palette: Fehler die nur einmal auftreten, Fehler die immer wieder auftreten, die nur bei einem bestimmten Nutzer auffallen oder solche die absolut zufällig auftreten.

Da müsste man sich jetzt hinsetzen und sich was ausdenken. Das ist aufwendig und man kann viele Fehler machen.

Nutzen Sie daher doch unser BugFramework und unsere BestBugLibrary. Damit stehen ihnen die wichtigsten Fehler für ihre Programme zur Verfügung und sie erhalten die Möglichkeit ganz einfach neue und innovative Fehler zu erschaffen.

Für kommerzielle Anwendungen steht neben der GPL-Version auch noch ein entsprechend attraktives Lizenzmodel zur Verfügung.

Verwandeln Sie ihr altes Test-Driven-Development Modell in ein zukunftsweisendes Bug-Driven-Development Plattform. Denn nur wer Fehler macht, kann sie auch beheben.

Keine Angst, das Web lebt. Auch wenn es überwiegend wohl noch ein 1.0 ist (und trotzdem nur ne beta).

Es bilden sich nur gerade verschiedene Trends heraus, die mit dem/über das Web in die Richtung Desktopanwendungen gehen. Dabei ist wohl das jüngste Mitglied (für mich zumindest) das Apollo Projekt von Adobe. Dabei geht es dann auch schon nicht mehr um Webanwendungen, die aussehen, wie eine Desktopanwendung, sondern um von Desktopanwendungen kaum unterscheidbare Programme.

Es geht nicht mehr um das Betriebssystem sondern um den Desktop. Und dabei ist es nicht mehr wichtig, was auf dem System installiert ist, sondern wie breit der Netzzugang ist. Denn ohne DSL geht es nicht.

Das Interessante daran ist die Vielfalt der möglichen Angebote, die (noch) ohne Zugangsbeschränkung in den freien Wettbewerb treten können. Und wenn ich an frei denke, dann denke ich auch an freie Software. Die Chancen, die sich aus Offenheit und Interoperabilität ergeben, könnten zu einem Systemwandel führen, bei dem proprietär Entwicklungen nur hinterher hinken können.

Und wieder hängt es ein klein wenig an der Freiheit, die wir uns selbst und anderen gewähren. 

Die aktuellen Entwicklungen im Webbereich lassen auf der Softwareentwicklungsseite eine große Lücke erkennen: das Userinterface.

Ajax und Co. versuchen auf einem ungeeigneten Protokoll und mit limitierten Darstellungsmöglichkeiten eine hoch interaktive Nutzerschnittstelle zu emulieren. Das mit solchen Techniken interessante Ergebnisse realisiert wurden, beantwortet aber nicht automatisch die Frage nach dem Sinn.

Es geht nicht mehr nur um Formulare und Eingabemasken. Zunehmend wird im Web auch Multimedia zelebriert, was in Anbetracht der Entwicklung der letzten Jahre zwar nicht verwunderlich ist, aber trotzdem erstaunt, wenn man bedenkt, daß im Bereich der Desktopoberflächen das Thema Multimedia erst lange nach der eigentlichen Nutzerschnittstelle angegangen wurde.
Wenn die Entwicklung nun eindeutig in eine Richtung zeigt, die eine Ablösung des klassichen Desktops durch (im Internet) verteilte Anwendungen vorantreibt, stellt sich nur die Frage nach dem Standard, der dabei zum Zuge kommt.

Schon einmal gab es die Idee eines Netzwerkcomputers, der auch schon damals Befürchtungen bei Microsoft hervorrief. Auch später reagierte Microsoft sehr empfindlich, wenn es darum ging, die Dominanz auf dem Desktop anzutasten. Wie wird dann erst die Reaktion ausfallen, wenn Anwendungen wie Google Spreadsheet wie eine normale Desktopanwendung laufen.
Ajax wird nicht die Antwort sein, aber Ajax ist eine Stufe. Die nächste Stufe wird sicherlich bald erklommen sein. Und dann gibt es vielleicht die ersten Anwendungen, die so leichtgewichtig wie Webseiten daherkommen aber so mächtig wie vollständige Desktopanwendungen sein werden. Das wird die Entwicklung im Webbereich und im Bereich der Desktopanwendungen grundlegend verändern.

Es geht also nicht mehr um die Frage, wie man eine Web 2.0 Anwendung entwickelt, sondern was noch bis Desktop 2.0 zu tun ist. 

In der Floskel "Manche Probleme lösen sich von selbst." steckt ein wahrer Kern. Ich glaube, diese Feststellung durfte jeder von uns schon einmal machen. Allerdings beschreibt dieser Satz nur eine passive Seite.

Die folgende Situationen dürfte jedem, der sich mit Softwareentwicklung beschäftigt, durchaus bekannt vorkommen.

• Man hat ein Problem und schlägt sich schon mehrerer Stunden damit herum, ohne auf eine Lösung zu kommen. Man ist sich sicher, dass es eine Lösung gibt, aber irgendwie funktioniert es vielleicht nicht so, wie man das erwartet.
• Man setzt irgendwas um. Am nächsten Tag fragt man sich, was man da eigentlich gemacht hat und warum das so kompliziert geworden ist. Man macht dann gleich mal ein Refactoring.
• Man hat ein Problem und hat dazu gleich eine Reihe von Lösungen, die aber irgendwie nicht den Kern des Problems treffen.

In solchen Fällen hat mir geholfen, dass ich das Problem zu diesem Zeitpunkt einfach ungelöst weggelegt habe. Ich habe mich nicht mehr aktiv damit beschäftigt. Ja, ich habe nicht mal mehr darüber nachgedacht.

Ich konnte dann aber sehr häufig feststellen, dass mir für die meisten Probleme innerhalb von 24 Stunden eine recht gute Lösung eingefallen ist. Dabei habe ich, wie ich bereits beschrieben habe, nicht aktiv drüber nachgedacht. Ich vermute mal, dass man zumindest als Mann dann dabei auch mal die andere Hirnhälfte benutzt (ist für Frauen vermutlich überhaupt nicht geeignet (was zu prüfen wäre)).

Dabei kann ich folgende Vorteile feststellen:

• Man hat weniger Kopfschmerzen, weil man sich weniger stark in ein Problem verbeißt (wenn man rechtzeitig diese Methode anwendet)
• Man hat mehr Zeit um einfachere Probleme zu lösen. Man kann besser parallelisieren.
• Die Lösungen sind im Schnitt besser und man spart effektiv Zeit, weil man meist eine Implementierung weniger umsetzen muss.
• Man denkt doppelt so schnell (wenn das mit der Hirnhälfte stimmt) 🙂

Es gibt auch Nachteile:

• Ich wüsste nicht wie man das erlernen kann. Man kann es nur ausprobieren und testen, ob der Effekt bei einem auftritt.
• Wenn man leider keine 24 Stunden Zeit hat, ist das evtl. keine Option.

Ich vermute, dass sich dieses Konzept auch auf andere Bereiche übertragen lässt, denn es gibt eigentlich keine Abhängigkeit in Richtung Softwareentwicklung. Insofern bin ich gespannt darauf, ob jemand ähnliche Beobachtungen gemacht hat und ob die in anderen Bereichen angesiedelt waren.

Ansonsten: Ausprobieren. Und liebend gerne die eigenen Erfahrungen schildern.