Software Engineering Blog

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

Hier ein kleiner Veranstaltungshinweis für alle Berliner. Marion Eickmann von agile42 hat es geschafft Mary Poppendieck für den nächsten Berliner Scrum-Stammtisch am 11. Oktober 2009 zu gewinnen.

Wer gerne am Stammtisch teilnehmen würde, erfährt auf dem agile42-Blog alles dafür notwendige.

Schon vor einiger Zeit habe ich auf ein inzwischen nicht mehr ganz so neues, aber trotzdem sehr interessantes Buch hingewiesen.

Jetzt habe ich es mir endlich gekauft und scheine sogar die Zeit zu haben, es zu lesen... Anschließend werde ich eine kleine Zusammenfassung schreiben. Obwohl ich glaube, daß sie sich inhaltlich mit denen auf der Produktseite von Amazon decken wird.

Von Eclipse als Entwicklungsumgebung war ich noch nie begeistert. Eclipse war mir immer zu groß, langsam und schwerfällig. Wohl auch berechtigt, wenn man im Vergleich dazu Intellij IDEA von Jetbrains aus St. Petersburg benutzt.

Daher hat mich "I stopped using Eclipse..." Artikel im Blog von Gernot Starke richtig aufrichtig gefreut.

Dazu passend hier noch ein Ausschnitt von der XING-Seite eines ehemaligen Kollegen:

Herzliche Grüße nach Bonn und Köln!

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