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ß.

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…

• 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...

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...

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.

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!

Was ist aber, wenn einfach nur festgestellt werden soll, ob einen Nachricht empfangen werden kann, also ob der Transportweg funktioniert? In Geschäftsanwendungen ist der Nachrichtenaustausch meist an Fachprozesse gebunden. Daher ist es nicht sinnvoll einfach zum Test eine Nachricht zu verschicken, soll auf der Empfangsseite keine Aktion ausgelöst werden. Doch wie kann der Transportweg anders getestet werden?

ping ist ein kleines Programm aus Unix-Urzeiten, mit dem die Erreichbarkeit von Rechnern in Netzwerken überprüfen läßt. Dafür verschickt es eine ICMP-Echo-Nachricht an einen Rechner und erwartet eine Antwort von diesem System, auch Pong genannt. Erhält ping keine Antwort, ist davon auszugehen, daß der Rechner nicht erreichbar ist.

Das gleiche Prinzip kann für Fachanwendungen genutzt werden. Hierzu muß lediglich eine eigene Ping-Nachricht für die Systemschnittstellen definiert werden, wobei folgende Anforderungen zu erfüllen sind:

• Ihre Übermittlung muß vom Zielsystem quittiert werden.
• Sie muß den gleichen Transport-Mechanismus durchlaufen wie die eigentlichen Nachrichten.
• Sie darf keinen fachlichen Prozess auf der Empfängerseite auslösen.

So definiert, steht ein universelles Werkzeug bereit, um den Nachrichtenaustausch leicht und zuverlässig testen zu können.

Josuttis schreibt darin über einem Vortrag auf der Agile 2008 zum Thema Software-Qualität, der von Robert C. Martin gehalten wurde. Martin stellt fest, daß wir in der Software-Branche zu viel Mist produzieren. Vorallen tun wir das, weil einfach zu wenig Zeit dafür zur Verfügung steht um sauber zu arbeiten zwischen all den Budgetplänen, Tagessätzen und Releaseterminen. Insofern ist das Sujet bekannt und die meisten von uns können das wohl aus der einen oder anderen Erfahrung bestätigen.

Das eigentlich interessante ist, daß Josuttis das wohl aus eigener Erfahrung kennt und auch darlegt, wie er versucht diesem Problem beizukommen und damit glatt die nächste Revolution in der IT-Welt vorhersagt.

Josuttis versucht dem Problem beizukommen, in dem die Entwicklung von Fachlichkeiten vom „Sauermachen“ trennt. Es gibt also zwei Gruppen. Die einen schreiben fleißig Code und die anderen bringen ihn in Ordnung. Schlechter Code ist demnach in Ordnung, da er später glattgezogen wird. An die großen Hypes Agilität und SOA anknüpfend entwickelt er diesen Gedanken weiter und stellt die Frage, warum wir nicht endlich schlechten Code akzeptieren, schließlich haben wir mit der Agilität sich wandelnde Anforderungen akzeptiert und sogar kultiviert und SOA das gleich mit heterogenen Systemen getan. Schlußendlich sollten wir aufhören, schlechten Code zu bekämpfen, sondern sinnvoll damit umgehen.
So sehr er mit vielem auch Recht hat, umso mehr irrt er hier doch und kommt zu einem falschen Schluß. Schlechter Code ist zu bekämpfen.

Eine allgemein gültige Definition von gutem Code gibt es nicht. Daher für aber viele von Qualität. Mir gefällt am besten die DIN-Definition, wonach Qualität „die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und abgeleitete Erfordernisse (Qualitätsanforderungen) zu erfüllen“ ist. Zugegebener Maßen klingt das etwas sperrig und erschließt sich nicht direkt, denn was sind „abgeleitete Erfordernisse“. Qualität hat viele Ausprägungen, wie da wären:

• Funktionalität
• Zweckdienlichkeit
• Sicher
• Robustheit
• Benutzbarkeit
• Zuverlässigkeit
• Änderbarkeit
• Portierbarkeit
• Prüfbarkeit
• Geschwindigkeit

Jeder wird zugeben, daß eine Software, die nicht die geforderten Funktionen bringt aus Kundensicht nichts wert ist. Insofern ist Funktionalität ein hinreichendes Qualitätsmerkmal, aber allein nicht ausreichend. Je länger eine Software lebt, umso wichtiger werden auch Merkmale wie Wartbarkeit und Änderbarkeit und können zum Schluß mehr über den Erfolg Ihrer Software entscheiden als die eigentliche Funktionalität.

Natürlich muß man am Code verzweifeln, wenn man die perfekte Architektur und eine konsistente Einhalt von Codierrichtlinien erwartet und hofft, daß alle Entwickler den gleichen Stil pflegen und sich mit der gleichen Hingabe ihrer Aufgabe widmen. Die Welt ist nicht perfekt und wir sind es nicht, warum sollte es unsere Software sein? Perfekte Software ist schlichtweg unmöglich. Sie ist unmöglich, weil sich die Welt rund um die Software ständig ändert. So ändern sich die Anforderungen, im Idealfall werden sie konkreter und damit für alle besser. Wir wissen besser, was unser Kunde will und der Kunde erhält eher das, was er braucht. So ändern sich die Tools mit denen wir arbeiten. Werden sie besser, so verbessert sich unser Stil Software zu entwickeln - oder wirft uns um Jahre zurück. So ändern auch wir uns. Mit jedem Projekt wächst unser Wissen und Können, auch wenn wir uns ehrlicher Weise auch bei ählichen Fehlern immer wieder selber stellen. Das war wir gestern geschrieben haben, ist uns Wissen, Können und Vermögen von gestern und das kann das Beste gewesen sein, was wir zu diesem Zeitpunkt leisten konnten.
Allerdings ist das alles kein Grund schlechte Software zu akzeptieren. Oder möchten Sie schlechte Software benutzen. Jeder von uns erwartet, daß der Geldautomat zu jeder Tageszeit funktioniert und nicht irgendwie, sondern richtig. Und freut sich, wenn das zu übernehmende Projekt gut geführt und die Sofware sauber implementiert ist.

Vielmehr sollten wir uns umso mehr bemühen gute Software mit perfekten Code zu entwicklen. Wie schon weiter oben geschrieben ist das Ziel nicht erreichbar, doch wenn wir es uns als Ziel setzen werden die Ergebnisse weit besser sein, als wenn wir uns von vornherein nur mit Mittelmäßigkeit begnügen. Denn sobald wir dies verinnerlicht haben, werden wir uns mit noch weniger zufrieden geben.

Daß wir heute im Bereich des Software Engineerings noch lange nicht die Erfolgsquote und Qualitätsziele erreichen wie in anderen Branchen, dürfte aber nicht nur daran liegen. Vielmehr wird Software Engineering noch zu sehr als Produktion von Software verstanden. Doch Software entsteht nicht am Fließband.

Jedes Projekt ist ein Entwicklungsprojekt, dessen Ergebnis wir am Anfang noch nicht kennen (können). Wir habennur eine Vorstellung von den ungefähren Zielen, die erreicht werden sollen. Oft ist der Weg dahin noch unbekannt oder unklar. Insofern ist jedes Softwareprojekt eher wie ein Forschungsprojekt zu betrachten. Das macht auch die Planung so schwierig, ist aber auch die Grundlage für die Freude an der Softwareentwicklung.