Software Engineering Blog

Wie gestern versproche, habe ich meinen Vortrag zu MapReduce und Apache Hadoop auf Slideshare online gestellt.

Wenn wir mit anderen zusammenarbeiten besteht immer die Gefahr sich gegenseitig zu stören. Wir arbeiten im gleichen Projekt, bearbeiten die selben Klassen, schreiben in die selbe Datenbank, gegen die der Kollege seine Tests fährt, machen Änderungen, die sich gegenseitig ausschließen. Oft stellt das kein Problem dar, wenn es koordiniert oder zumindest mit dem Wissen der Kollegen geschieht. Was ist aber, wenn wir genau das nicht wollen? Wenn wir in Ruhe die nächsten zwei Wochen an einem ganz besonderen Feature arbeiten wollen oder ein größeres experimentelles Refactoring vornehmen wollen? Es geht aber nicht nur um die großen Aufgaben. Auch in unserer alltäglichen Arbeit, sollte die Gefahr mit der Arbeit Anderer zu kollidieren möglichst gering sein.

Wir müssen uns also isolieren können und unsere Entwicklungslandschaft muß das unterstützten, uns dafür die technischen Möglichkeiten geben. Solange es für ein gesamtes Team nur eine Datenbank, auf der alle arbeiten, oder nur einen Application Server gibt, gelingt das nicht. Solche Systeme nenne ich immer scherzhaft Synchronisationssingularitäten, also Punkte, an denen alle Arbeiten zusammenlaufen laufen. Aber was bedeutet jetzt Isolation für eine Entwicklungslandschaft?

Hier meine Definition:

Isolation ist die Fähigkeit einer Entwicklungslandschaft an dem SUD (System Under Development) Änderungen vorzunehmen, ohne dabei von Anderen ungewollt beeinflußt zu werden oder Andere ungewollt zu beeinflußen.

Ein sehr gutes praktisches Beispiel für Isolation unterstützende Werkzeuge in einer Entwicklungslandschaft sind Versionsverwaltungssysteme wie Subversion oder Git, das die Isolation durch seinen dezentralen Ansatz noch weiter vorantreibt als früher CVS oder jetzt Subversion. Aber der Einsatz eines Versionskontrollsystems kann nur ein erster Schritt sein. Abgesehen davon: zeitgemäße Softwareentwicklung ohne Versionskontrollsystem ist ein Widerspruch in sich.

Heute lassen sich die meisten Systeme, die wir für Entwicklung und Test benötigen ohne Probleme für jeden Entwickler bereitstellen. Eine eigene Datenbank auf dem Laptop, ein lokaler FTP- oder Mailserver oder auch Applikation-Server sind immer möglich. Manche dieser Systeme müssen sogar nicht festinstalliert werden, sondern können im Rahmen eines Builds installiert und konfiguriert werden. JBoss, GlassFish und Apache Tomcat können aus ZIP-Archiven vollständig installiert und angepaßte Konfigurationsdateien anschließend generiert werden. Wird eine saubere Installation gebraucht, wird die alte gelöscht und eine neue automatisch installiert. Mit etwas Ehrgeiz ist das durchaus möglich.

Aber Isolation bringt noch weitere Vorteile für die Software-Entwicklung:

• Ruhe und Ungestörtheit, weil es nicht ungewollt zu Konflikten mit den Arbeiten von anderen Entwicklern im Team kommt. Änderungen werden nur noch gewollt zusammengeführt.
• Verbesserung der Reproduzierbarkeit, weil alle positiven und negativen Effekte nur durch mich selber verursacht wurden und beispielsweise Testergebnisse so nicht verfälscht werden.
• Besseres Konfigurationsmanagement und Setup, weil Isolation als Ziel besondere Maßnahmen erfordert, die zwangsläufig auch zu Zielen wie besserer Modularisierung und Konfigurierbarkeit führen.

Wenn wir beim Aufbau unserer Entwicklungslandschaft Isolation konsequent von Anfang an verfolgen und beachten, erhalten wir die Chance besser im Team zusammenarbeiten zu können, weil wir es dann geschafft haben gegenseitige Abhängigkeiten weiter aufzulösen. Gerade für agil arbeitende Teams sollte Isolation immer ein zu erreichendes Ziel sein, den deren Fehlen stört den Arbeitsfluß.

Alle zwei Jahre steht auch bei mir eine Verlängerung des Handyvertrags an und die je nach Anbieter unterschiedlichen Angebote sorgen dafür, daß wohl viele Handys in Deutschland nach zwei Jahren den Besitzer wechseln. Der Erstbesitzer macht einen Technologiesprung und es findet sich doch immer jemand im Bekanntenkreis, der ein (neueres) Handy gebrauchen könnte.

So auch bei mir und daher besitze ich jetzt seit zwei Wochen ein Nokia E71. Sicherlich, nicht das aktuellste Modell auf dem Markt, aber genau das was ich brauche. Zumindest glaube zu brauchen. Es ist klein, handlich und leichter als mein altes E61. Und es hat unerwartete Nebenwirkungen: ich höre jetzt auch Podcasts. Auf dem Laptop war mir das immer nicht bequem genug. Schlimmstenfalls muß man da auch noch zuhören, sich also konzentrieren. Das klappt zwar neben der Arbeit, aber geht auch zu deren Lasten. Jetzt ist das anders. Die Podcasts aktualisieren sich automatisch über mein WLAN und da das Handy praktisch überall dabei ist, findet sich immer irgendwo etwas Zeit für ein wenig Edutainment. Aber nun zur Sache...

So komme ich endlich auch einmal dazu mir Podcasts des Software Engineering Radios anzuhören. So zum Bespiel die Episode 148 mit Dave Thomas zum Thema Software-Archäologie.

Thomas führt in diesem Podcasts ein paar interessante Dinge aus. Zum Beispiel, daß er am Code sehen kann, unter welchen Umständen die Software geschrieben wurde. Für mich ist das nachvollziehbar, denn unsere Arbeitsumstände haben einen maßgeblichen Einfluß darauf wie wir arbeiten und was wir erreichen können. Das erinnert mich aber auch an Conways Gesetz… Suchen sie einmal danach im weltweiten Gewebe.

Während des Podcasts wird auch das Thema Lesen von Code behandelt und daß dies eine viel zu stark vernachlässigte Disziplin ist. Das findet absolut meine Zustimmung. Und jeder der in Teams arbeitete weiß wie schwer ist manchmal schon sein kann, zu verstehen, was der Kollege da geschrieben hat und seine Gedankengänge nachzuvollziehen. Wie schwer ist es also erst sich in ein ganz fremdes System einzuarbeiten, eventuell noch auf einer anderen technischen Basis? Neulich habe ich mich mit der Implementierung von Hadoop beschäftigt. Und dabei mußte ich selber wieder erstaut feststellen, daß selbst wenn man im Grunde weiß wie etwas funktioniert, es doch eine Weile dauert ehe man die entsprechenden Teile im Code gefunden hat und zu verstehen beginnt, wie diese zusammenspielen. Am Ende ist es aber auch ein gutes Gefühl nicht nur zu wissen wie etwas ungefähr funktioniert, sondern es genau zu verstehen.

Thomas bemängelt in dem Podcast, daß in der Ausbildung an den Universitäten diese Disziplin nicht gelehrt wird. In anderen Fächern, wie den Geisteswissenschaften etwa, sei es gang und gäbe sich mit der Arbeit von anderen zu beschäftigen, indem deren Bücher und andere Veröffentlichungen von relevanten Autoren gelesen, analysiert und kritisiert werden.

Auch Mediziner lernen die menschliche Anatomie nicht beim ersten Kontakt mit den Patienten kennen, sondern schon bei der Sektion. Stellen sie sich einmal vor, sie kommen zu einem Arzt und hören: „Ah, so sieht das aus. Noch nie gesehen... Darf ich da einmal anfassen?“ Sie würden kopfschüttelnd den Raum verlassen und diesen Arzt für immer meiden.

Also warum nicht, wie Thomas es vorschlägt, Seminare an Universitäten anbieten, die sich nur mit der Analyse von bestehender Software beschäftigen? Nicht nur mit den abstrakten Konzepten, sondern mit deren konkreter Umsetzung durch exisitierende Systeme.

Das ist nicht schwer. Java ist eine leichte Sprache und die Unterstützung durch Entwicklungsumgebungen ist sehr gut. Große quell-offene Softwareprojekte sind im Java-Umfeld frei verfügbar. Ich nenne hier nur einmal die üblichen Verdächtigen: Hibernate, Tomcat, JBoss, …

Jedes dieser Systeme setzt freiverfügbare Standards wie JPA, Servlet, JSP und EJB um. Warum nicht die Umsetzung dieser Standards untersuchen am Beispiel von konkreten Implementierungen. Welche Algorithmen lassen sich finden? Wie sieht die Architektur aus und wird diese auch konsequent umgesetzt?

Davon würde jeder profitieren können. Also, vielleicht gibt es ja einen Leser dieses Blocks, der sich dieser Idee annehmen möchte…

Woher das Wort Schnelligkeit kommt weiß ich leider nicht. Auch ein Blick in den Kluge konnte mir nicht weiterhelfen. Für eine Entwicklunglandschaft bedeutet Schnelligkeit aber etwas ähnliches wie für den Sportler. Im Sport wird Schnelligkeit in zwei Arten aufgeteilt:

• Aktionsschnelligkeit und
• Reaktionsschnelligkeit

Aktionsschnell ist jemand, der etwas in kürzerer Zeit machen kann als andere, zum Beispiel Laufen. Reaktionsschnell ist jemand, der sich in kurzer Zeit auf Signale und Reize reagieren kann.

Auch Entwicklungsumgebungen kennen solche zwei Arten der Schnelligkeit. Die Aktionsschnelligkeit einer Entwicklungumgebung ist die Fähigkeit Entwicklungsaufgaben in möglichst kurzer Zeit effizient durchführen zu können.

Eine gute Build-Umgebung erlaubt es uns schnell überprüfen zu können, ob unser Code gebaut werden kann. Eine gute Testumgebung schafft uns die Möglichkeit unsere Änderungen schnell überprüfen zu können. Habe ich etwas kaputt gemacht?

Eine Entwicklungslandschaft kann zwar nicht reaktionsschnell sein, zumindest nicht direkt, aber sie kann eine hohe Änderungsschnelligkeit haben. Das heißt nichts anderes, als daß sich Änderungen in der Entwicklungslandschaft schnell vornehmen lassen.

Bis hier wird jeder sicherlich zustimmen können und jeder wird wohl auch ein Build-Script haben, daß seinen Code baut oder zumindest etwas ähnliches. Doch gehört dazu noch mehr als das, was in den meisten Entwicklungsumgebungen zu finden ist. Uns geht die Aktionsschnelligkeit verloren, wenn wir bei häufigen Tätigkeiten immer manuell eingreifen müssen. Wir sind zwar bei den einzelnen Schritten schnell, verlieren dann aber Zeit beispielsweise mit Kopieren von Dateien oder ähnlichem.

Aber wozu brauchen wir diese Schnelligkeit eigentlich? Sicher will keiner lange auf irgendetwas warten. Das ist klar. Wir brauchen diese Schnelligkeit vorallem für eins: um flexibel zu bleiben. Wir alle sind in der einen oder anderen Art faul und sobald bestimmte Aufgaben uns zu aufwendig erscheinen, versuchen wir sie zu umgehen. Wir bauen oder testen weniger und ab dem Punkte sind wir auf dem absteigenden Ast...

Und wie kommen wir zu einer schnellen Entwicklungsumgebung:

• Analysieren Sie die Abhängigkeiten in ihrer Entwicklungsumgebung und durchtrennen sie sie dort, wo sie nicht notwendig sind.
• Cachen Sie Zwischenergebnisse wo immer möglich. Nicht alles muß immer wieder erzeugt oder generiert werden.
• Wählen sie die richtigen Tools aus.

Um wirklich schnell zu sein, braucht es aber auch einen hohen Automatisierunggrad. Aber das ist ein anderes Thema...

Softwareentwickler verbringen die meiste Zeit ihrer Arbeit mit ihrer Entwicklungsumgebung. Daher bin ich oft überrascht, auf welch schlecht aufgebauten Entwicklungsumgebungen ich in Software-Projekten stoße.

Vielleicht sollte ich aber eher von Entwicklungslandschaft als von -umgebung sprechen, da für mich alles zur Entwicklungslandschaft zählt, was wir für unsere Software-Entwicklung benötigen. Das schließt alles mit ein, angefangen vom Datenbanksystem bis hin zu Issue-Tracking-System.

Schon Ian Sommerville nennt als eine zentrale Anfoderung an Software-Entwicklungsumgebungen (-landschaften), daß verschiedene Werkzeuge für unterschiedliche Phasen zur Verfügung stehen sollen, die Menge der Funktionen der Entwicklungsumgebung aber zu jeder Zeit durch neue Werkzeuge erweitern lassen muss, um neue Funktionen integrieren zu können, da wir nicht wissen, welche Funktionen später umzusetzen sind. Kurz gesagt, sie soll flexibel sein.

Oft sind Entwicklungslandschaften jedoch das ganze Gegenteil: starr und sogar hinderlich bei der Arbeit. Im einfachsten Falle kosten sie einfach nur Zeit. Die Probleme in einer Entwicklungslandschaft fangen schon an, wenn mehrere Entwickler dazu gezwungen sind auf der gleichen Datenbank parallel zu entwickeln und enden in stundenlangenen Installationen von Tools und deren Konfiguration.

Dabei muß unsere Entwicklungslandschaft genauso flexibel oder besser gesagt agil sein wie wir selber. Die gute Entwicklungsumgebung muß uns bei allen Änderungen unterstützen, uns einladen neues auszuprobieren und flexibel zu bleiben. Sobald wir eine Änderung, einen Test oder Idee verwerfen, nur weil sie nicht mit angemessenem Aufwand mit unserer Entwicklungslandschaft umzusetzen ist, ist es Zeit über sie nachzudenken.

Damit dies einfacher fällt, habe ich hier meine Kriterien für eine gute Entwicklungslandschaft zusammengestellt:

• Angemessenheit Eine Entwicklungslandschaft muß vom Entwicklungs- und Pflegeaufwand zur Projektgröße und -dauer passen. Je größer, je länger oder je mehr Entwickler an dem Projekt teilnehmen, desto mehr rentiert sich auch ein größerer Aufwand für die Entwicklungsumgebung.
• Zweckdienlichkeit Alle Komponenten der Entwicklungslandschaft sind effektiv für ihren Einsatzzweck und effizient einsetzbar.
• Isolation Jeder Entwickler muß die Möglichkeit und Sicherheit haben, Änderungen unabhängig von anderen durchführen zu können und auch nicht durch die Änderungen anderer ungewollt beeinflußt zu werden. Und hierbei denke ich nicht nur an den Einsatz eines Versionskontrollsystems.
• Automatisierung Wiederkehrende Tätigkeiten müssen automatisierbar sein. Die Entwicklungsumgebung muß hierfür die notwendige Unterstützung anbieten. Stichwörter sind hier beispielsweise Ant und Maven.
• Schnelligkeit Jede regelmäßig ausgeführte Tätigkeit muss sich in der Entwicklungslandschaft schnell ausführen lassen.
• Anpassbarkeit Jeder Entwickler muß die Möglichkeit haben seine persönliche Entwicklungslandschaft an seinen Erfordernissen entsprechend zu konfigurieren.
• Erweiterbarkeit Neue temporär und permantente Funktionen müssen sich leicht in die bestehende Entwicklungslandschaft integrieren lassen.
• Neutralität Einzelne Komponenten der Entwicklungslandschaft müssen sich leicht gegen andere Tools mit einer äquivalenten Funktionalität austauschen lassen. Funktionalität und Werkzeug müssen also so weit wie möglich orthogonal sein.

In den nächsten Tagen werde ich die einzelnen Punkte näher erläutern...

Vor einiger Zeit habe ich ein Phänomen beschrieben, welches ich Event-Driven-Software-Development nenne und dessen Kern von Martin Fowler als Technische Schulden beschrieben wird.

In Fowlers Blog habe ich jetzt einen Verweis auf ein Video von Ward Cunnigham gefunden, in welchem er den Begriff Technische Schulden erläutert und in 4 Minuten und 44 Sekunden auf den Punkt bringt.

Gernot Starke hat in seinem Blog einen Hinweis auf seinen auf der WJAX
gehaltenen Vortrag zum Thema Architekturkommunikation hingewiesen, der als Video online zur Verfügung steht.

Starke widmet sich in seinem Vortrag dem Zusammenhang von Architektur und Kommunikation und weiß das überzeugend zu vermitteln.

Nach seiner Ansicht ist eine der wesentlichen Aufgaben eines Architekten die Kommunikation mit allen am Projekt beteiligten Stakeholdern. Richtig dachte ich nur während des ganzen Videos. Gute Architekturen zu entwerfenist das eine, sie zum Leben zu erwecken und zu halten etwas anderes. Dafür
müssen alle miteingebunden werden, die davon betroffen seien könnten. Und leider muß es muß auch immer wieder wiederholt werden.

Hier ein paar nebenbei notierte Aussagen von Starke:

• Architektur beschäftigt sich mit Strukturen und Konzepten.
• Implizite Annahmen treten immer da auf, wo etwas nicht
  dokumentiert ist, wo es notwendig gewesen war. (Alt bekannt!)
• Implizite Annahmen schaffen Mißverständnispotential. (Ich nenne
  das einfach mal heterogene Projektentwicklung. Klingt doch
  netter.)
• Architektur ist nicht das Kodieren von selbigen, da Code
  allein ab einer gewissen Größe keine Basis für Verständnis
  ist.
• Verständnis (von Architekturen) muß erst geschaffen werden und
  kann erst danach gefördert werden.
• Dokumentation muß minimalistisch sein, womit gemeint ist, daß
  nur die relevanten oder stabilen Punkte dokumentiert werden sollten,
  die für das Verständnis der Anwendung notwendig sind.
• Dokumentation muß wartbar sein.

Starke schafft es diese Punkte überzeugend zu vermitteln.

Fazit: Anschauen!

Schnittstellen zwischen Systemen, sind heute as A und O vieler Systeme. Gerade für Geschäftsanwendungen ist der Datenaustausch mit anderen Systemen ein zentraler Leistungsaspekt. Doch wie kann sichergestellt werden, daß alle Systeme erreichbar sind? Bei direkt gekoppelten Schnittstellen mit einem synchronen Aufruf kein Problem. Doch was kann tun, wenn die beteiligten Systeme nur indirekt und asynchron kommunizieren können? ping zeigt und hier den Weg auf.
(weiterlesen...)

Regelmäßig lese ich „The World of IT“ und „Bernds Management Blog“ auf den Seiten der iX, die von OOSE-Chef Bernd Österreich, Jutta Eckstein und Nicolai Josuttis geschrieben werden. Mit durchschnittlich einer Veröffentlichung pro Monat ist es auch ein leichtes jede Veröffentlichung zu lesen. Falls Sie auch diese Blogs lesen: Ist Ihnen schon einmal aufgefallen, daß jeder der genannten eine für eine bestimmte Grundhaltung steht? An welche ich dabei denke will ich heute für mich behalten, besonders da ich mich mit dem letzten Beitrag von Nicolai Josuttis auseinander setzen möchte.
(weiterlesen...)

Wenn das ObjectSpektrum nicht seine aktuellen Ausgabe dem Thema 40 Jahre Software Engineering gewidmet hätte, wäre dieses Ereignis wohl auch an mir ohne besonderen Wahrnehmung vorbei gegangen. Zugegeben, 40 Jahre sind kein rundes Jubiläum, aber ein guter Anlaß um das Thema wieder in den Mittelpunkt zu rücken.
(weiterlesen...)