Direkt zum Hauptbereich

Was einen guten Entwickler aus macht

Keine Frage wir Softwareentwickler kommen schon mit unseren Tools und unserer Sprache klar. Und am Ende des Tages liefern wir das Feature, welches der Kunde haben wollte, oder zumindest eins, welches er abnimmt aus. Aus kurzfristiger Projektsicht sind die guten Entwickler jene, welche die meisten, größten, kompliziertesten etc. Features beigesteuert haben. Und die, welche man mal eben noch in das Projekt holt, um irgendwie den Zeitplan zu halten.



Meiner Ansicht nach, und das hat eine ganze Weile gedauert, bis ich zu dieser gekommen bin, macht einen guten Entwickler aber wesentlich mehr aus, als ein Projekt in-Time abzuliefern.
Der gute Entwickler denkt und handelt im Sinne des Unternehmens langfristiger und nachhaltiger. Bei seinen Lösungen achtet er da drauf, dass das aktuell entwickelte System auch langfristig ein Erfolg für das Unternehmen ist. Dazu ist es wichtig, dass sein Code wartbar ist und möglichst wenige unentdeckten Fehler aufweist. Dazu gehört dass er seine Funktionalität durch gute Tests abdeckt, so dass Änderungen ohne Regressionsfehler gemacht werden können. Des weiteren macht er sich Gedanken zu einem erweiterbaren Design. Er sorgt dafür, dass sein Code auch von anderen Verstanden und gewartet werden kann. Denn wenn eine Änderung kommt oder ein Fehler auftritt, ist es nicht unbedingt der selbe Entwickler, welcher dann an den Code kommt. Dazu gehört auch ein ständiges Refactoring.

Um ein Feature / Projekt so um zu setzen gehört auch, dass der Entwickler seine Tools beherrscht und in ihrem Sinne nutzt. Ich Programmiere nicht dadurch Java 7, dass mein Compiler auf die Version eingestellt ist, sondern dadurch dass ich die Konzepte Verstanden habe und nutze. Ein nicht verstandenes aber angewendetes Konzept führt unweigerlich auch dazu, dass der Code schlechter wartbar wird.

Hinzu kommt, dass ein guter Entwickler aktiv im Team arbeitet. Also, dass er nicht nur mit anderen in einem Projekt arbeitet, sondern dass er sich auch mit diesen Austauscht und Lösungen diskutiert. Dass er mit ihnen sein Wissen teilt und eine gemeinsame Lösung und einen gemeinsamen Stil anstrebt.

Nur so kann ein Entwickler dafür sorgen, dass ein Projekt auch Langfristig nicht zum Boomrang wird und die Wartungsaufwände alle jemals eingefahrenen Gewinne auffressen oder Änderungen unmöglich werden.

Klar ist aber auch, dass man nicht in Schönheit sterben sollte und einen pragmatischen Mittelweg finden muss, damit das Projekt fertig wird.

Wenn er nun noch Versucht den Wert eines Features für den Kunden zu verstehen, anstatt einfach das spezifizierte umzusetzen kommt man zu langfristig guten Produkten.

Nicht zu letzt vergisst er aber auch die anderen "Abteilungen" nicht. Das Feature / Produkt ist nicht fertig, wenn es im Repository ist sondern wenn es in Betrieb ist. So sollte sich der Entwickler auch aktiv da drum bemühen, sicherzustellen, dass der Betrieb das System installieren und überwachen kann. Und den Vertrieb gibt es ja auch noch. Was könnte dieser erwarten?


Kommentare

Kommentar posten

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte.

Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen verteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität.

Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus:

Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit.

Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist.
(Was nun was bedingt, lass ich mal dahingestellt)

Dadurch haben sich natürlich auch die Struktur…

Speed Temenos auf dem AgileDay der JAX

Letzte Woche hatte ich die Gelegenheit auf dem AgileDay der JAX zu sein. Neben Vorträgen am Vormittag mit Beiträgen zu Retrospektiven agile in Konzernen sowie einer spezifischen Implementierung in einem Unternehmen stand nach der Mittagspause ein Speed Temenos mit Olaf Lewitz und Christine Neidhardt auf dem Programm. Zur Unterstützung hatten sie sich Unterstützung über die Softwerkskammer organisiert, so dass die Anwesenden von insgesamt 20 Facilitatoren betreut wurden.

Bei Temenos handelt es sich um einen "geschützten Raum" in dem Menschen Offenheit und Vertrauen erleben können. Das Speed Temenos mit seinen 3 Phasen, in welchen es um die Persönliche (Berufliche) Vergangenheit, den Ist-Zustand und die Vision für die Zukunft geht hilft über Geschichten erzählen, sich selbst zu reflektieren und Gemeinsamkeiten in der Gruppe zu entdecken. Details sind auf http://trusttemenos.de/ viel besser erklärt als ich es hier kann.

Ich hatte Temenos mit Olaf bereits auf der Play4Agile 201…