Foto: Diversity of Beauty von Evan Leeson (Lizenz: CC-BY-NC-SA)

5 lesenswerte Artikel zu unterschiedlichen Themen aus der Softwarebranche:

Teamwork

Teamdynamik ist für sich genommen schon ein faszinierendes Thema. Was nimmt man aber erst mit, wenn man fast ein Jahr auf engstem Raum zusammenlebt und den Elementen trotzt? Was lernt man über sich und die anderen? Tony Haile hat es herausgefunden und gibt interessante Einsichten preis.

Tony Haile: Four things I learned on a round-the-world yacht race

Wie Programmiersprachen unsere Denkweise beeinflussen

Es ist kein Geheimnis, dass ich Ruby als Programmiersprache sehr schätze. Damit einher geht ein ungutes Gefühl gegen gewisse andere Sprachen, ohne recht zu wissen wieso. Steve Yegge hat einen sehr treffenden Punkt gegen Java aufgegriffen und ihm einen (langen!) Blogpost gewidmet.

Steve Yegge: Execution in the Kingdom of Nouns

Checkliste für Sysadmins

Mit meinem Interesse an DevOps wächst auch jenes an der Arbeitsweise von Administratoren. Diese Liste ist ein wahrer Rundumschlag, wenn es um Methoden und Praktiken in der Systemadministration geht.

Everything Sysadmin: 32 Questions for Your Sysadmin Team

Ruby-Programmierpraxis: Law of Demeter

Programmcode muss vorsichtig entwickelt werden, wenn er bestehen soll. Um Wildwuchs zu vermeiden, gibt es mit dem Law of Demeter einen Daumenregel, um strukturelle Kopplung in den Code zu bringen.

Avdi Grimm: Demeter: It’s not just a good idea. It’s the law.

Was wir von Casinos über Webdesign lernen können

Zu guter Letzt noch etwas Wissenschaftliches: Wie die Architektur von Casinos den Umsatz in ihnen beeinflusst. Daraus lässt sich einiges zum Design von z.B. Landing Pages ableiten.

Wired: Why Being Relaxed Makes Us Spend Too Much Money

Du wachst nicht eines Tages auf und fängst an, gute Tests zu schreiben.

Dahinter steckt ein Prozess, eine Verwandlung. Zoologen sprechen von der „Umwandlung der Larvenform zum Adultstadium“.

Foto: Wooden Wings von MrClean1982 (Lizenz: CC-BY-NC)

Die Raupe wird zum Schmetterling.

Aber welche Stufen der Entwicklung durchlaufen Testautoren dabei nun genau?

Der Sturkopf

Der Sturkopf ist der Meinung, er käme ohne Tests schneller voran. Verschleiert mit durchaus plausiblen „Vorbehalten“ (die er mit sachkundigeren Kollegen teilt) die Tatsache, dass ihm kaum Vorzüge von Tests einfallen und er Tests bisher praktisch nicht angewandt hat.

Hat wahrscheinlich nie ein komplexes Projekt über einen längeren Zeitraum im Team entwickelt. Oder von anderen übernehmen und dann erweitern müssen. Oder einen neuen Kollegen in eine umfangreiche Code-Basis einarbeiten dürfen.

Der Sturkopf gehört zu den bedrohten Arten, muss aber nicht geschützt werden.

Wenn der Sturkopf sich irgendwann doch noch von Tests überzeugen lässt, wird er zunächst…

Der Anfänger

Der Anfänger hat die Notwendigkeit von Tests begriffen, kämpft aber meist noch mit den Grundlagen von Tests: Wie teste ich richtig? Was ist wichtig? Wie strukturiere ich Tests?

Der Anfänger wählt häufig den kompliziertesten Weg, um einfache Dinge zu testen. Aber das ist durchaus in Ordnung, wir alle lernen jeden Tag.

Schlecht ist dagegen, wenn aus der anfänglichen Unsicherheit Übereifer und sogar Obsession wird. Der Anfänger wird dann mit einiger Wahrscheinlichkeit…

Der Test-Nazi

Der Test-Nazi schreibt Tests für alles, was nicht bei drei auf den Bäumen ist — völlig unbeirrt von der Frage nach dem Nutzen.

Beherrscht Stubbing und Mocking perfekt, ohne sich der Gefahren dieser Methode bewusst zu sein (oder schlimmer noch: sie billigend in Kauf nehmend).

Achtet auf 100%-ige Testabdeckung des Codes. Zählt andere an, wenn nicht alle Ausnahmen im Code getestet sind. Achtet peinlichst auf Test-Design (z.B. DRY).

Doch spätestens, wenn er das erste Mal einen Großteil des Codes under Test löschen konnte, ohne dass die betroffenen Tests fehlschlagen, erkennt er die Folgen seines Tuns. Er erreicht die höchste Stufe der Entwicklung und wird…

Der Pragmatiker

Der Pragmatiker ist von Erfahrung geprägt. Er weiß um die Notwendigkeit von Tests (auch in Vorbereitung auf umfangreiche Refactorings) und die Gefährlichkeit von Stubbing/Mocking — gebranntes Kind scheut das Feuer.

Setzt auf Vernunft bei der Testabdeckung, weil er den den geschäftlichen Nutzen im Blick hat. Schreibt auf diese Weise Tests, die auch tatsächlich wirtschaftlich sind.

Fazit

Diese Liste erhebt nicht den Anspruch, vollständig zu sein, sondern beruht auf persönlichen Beobachtungen.

Was ist deine Erfahrung mit den Entwicklungsstufen auf dem Weg zu guten Testautoren? Welche Typen kennst du? Sag’s uns in den Kommentaren.

Foto: Jumping in the sunset von thriol (Lizenz: CC-BY-NC)

Matthias Marschall war so freundlich, einige grundsätzliche Fragen zu DevOps zu beantworten.

Matthias ist im Web-Umfeld tätig und befasst sich mit dem Thema, seit er vor acht Jahren neben der kompletten Entwicklung einer großen Web-App auch für den Betrieb Verantwortung übernommen hat. Er lehrt Agile Methoden in Augsburg, bloggt über Agile Web Operations und will mit Dan Ackerson Techniker bei der Umsetzung von DevOps unterstützen.

DevOps sieht sich selbst als Bewegung. Wie kam es dazu?

Viele der Ideen, die jetzt unter dem Begriff DevOps zusammengefasst werden, gibt es natürlich schon lange. Seinen Anfang als Bewegung hat DevOps mit den ersten DevOpsDays genommen, die von Patrick Debois organisiert wurden.

Was sind eure Ziele?

Das Ziel von DevOps ist es, die Kluft zwischen Entwicklung und Betrieb zu schließen, um so den Anforderungen an immer schnellere und flexiblere Änderungen gerecht werden zu können — vor allem bei Web Applications, aber nicht nur. Es geht im Endeffekt darum, die Grundideen von agilen Methoden auch auf Operations auszuweiten und somit einen nahtlosen Prozess von der Entwicklung hin zum Nutzer zu schaffen. Denn erst wenn der Nutzer was von der entwickelten Software hat, ist man wirklich erfolgreich.

Wie groß ist die Bewegung mittlerweile?

Das ist natürlich schwer zu sagen. Eric Knorr hat in Devops and the great IT convergence geschrieben:

According to a friend in the space, all you need to do is walk through Silicon Valley and shout, “Devops,” and 300 people will run to a meetup.

Und auch auf den DevOpsDays kommen immer wieder weit über 100 Leute zusammen.

Als Entwickler sehe ich hier Operations in der Bringschuld. Bei uns sind die Administratoren diejenigen, die sich zurückziehen und kaum Präsenz auf Meetings zeigen, während ich mir Feedback aus Projekten abhole und mit Kollegen in Kontakt stehe. Wer muss den ersten Schritt machen?

Es ist sicher so, dass in der Entwicklung agile Ideen und Vorgehensweisen schon weiter verbreitet sind als in Operations. Viele Administratoren bekämpfen Änderungen noch und wollen ein möglichst stabiles System schaffen. Diese Denkweise ist nicht mehr zeitgemäß. Alle müssen zusammen arbeiten, um möglichst schnell Änderungen an Kunden auszurollen, natürlich ohne Operations zu gefährden.

Matthias Marschall

Es hilft natürlich nicht drauf zu warten, dass irgend jemand den ersten Schritt macht. Jeder, der verstanden hat, um was es bei Agile und DevOps geht, sollte bemüht sein, alle Beteiligten mit ins Boot zu holen.

Ausgehend von den üblichen Gräben zwischen Entwicklern und Administratoren: Wie lange dauert es, bis DevOps im Unternehmen etabliert sind?

Tiefgreifende kulturelle Änderungen dauern Monate oder sogar Jahre bis sie sich im Unternehmen etabliert haben. Je weniger es alle Beteiligten gewohnt sind zusammen zu arbeiten, desto länger.
Es ist wichtig, dass man Vertrauen zwischen Entwicklern und Administratoren schafft.

Welche konkreten Maßnahmen helfen dabei?

Zunächst ist ein gegenseitiger Zugriff auf die Ressourcen hilfreich: Zugriff für die Entwickler auf die Produktionsmaschinen, um Fehler direkt analysieren zu können, und für die Administratoren auf das Source Code Repository und die Build Tools, damit sie selbst Testbuilds deployen können, um sich damit vertraut zu machen. QA sollte von Anfang an in den Entwicklungsprozess mit eingebunden sein — QA kann z.B. schon Testszenarien für User Stories als Akzeptanzkriterien definieren, lange bevor die Entwicklung anfängt. Entwickler können in die Bereitschaftsdienste mit aufgenommen werden. Und nicht zuletzt Transparenz herstellen, indem man Metriken und Planungen offenlegt.

Natürlich ist da die eigene Kreativität gefragt. Es kommt sehr genau auf das Umfeld und die aktuelle Situation an.

Es gibt Vorwürfe, DevOps sei elitär und eure Ideen nur alter Wein in neuen Schläuchen. Wie geht ihr mit solcher Kritik um?

Wie gesagt, sind natürlich viele Ideen, die jetzt als DevOps bezeichnet werden ganz und gar nicht neu. Was neu ist, ist, dass wir versuchen, ein breiteres Verständnis für die Dringlichkeit der Zusammenarbeit zu erzeugen und Wege zu sammeln und aufzuzeigen, um schneller bessere Software zum Kunden zu bringen. So in dieser Gesamtheit hat das meines Wissen noch keiner versucht.

Vielen Dank für die ausführlichen Antworten!

Foto: Serve Me von Kevin Lau (Lizenz: CC-BY-NC-ND)

Softwarepatente

Everyone in the software field has seen a parade of patents which do nothing but try to claim rights on techniques that have already been in use for years, let alone developments that while new, are are still obvious to those of us with ordinary skills in programming.

Martin Fowler: Software Patents

Robotron und Oracle

Computerprogramme aus der DDR? Die brauchte nach der Wende nun wirklich keiner mehr, glaubte man damals in der IT-Branche. Einer sah das anders. Rolf Heinemann machte aus dem Großkombinat VEB Robotron mithilfe eines Freundes ein internationales Software-Unternehmen.

brand eins: Der Überläufer

Falsche Annahmen über Namen

Aus eigener Erfahrung kann ich sagen, dass ein Accent im Namen schon immer Probleme bereitet hat. Auch noch Jahre später.

Daher habe ich mich gefreut, dass Patrick McKenzie gleich eine ganze Liste über falsche Annahmen bzgl. Namen erstellt hat:

So, as a public service, I’m going to list assumptions your systems probably make about names. All of these assumptions are wrong. Try to make less of them next time you write a system which touches names.

Patrick McKenzie: Falsehoods Programmers Believe About Names

Modernes Intranet

Das Intranet der Zukunft ist gleichzeitig auch soziales Netzwerk: Jeder ist mit einem Profil vertreten, aus dem Interessen und Kompetenzen hervorgehen. Die Mitarbeiter können eigene Inhalte einstellen und ihr Wissen mit den Kollegen teilen. So wird das Expertenwissen innerhalb eines Unternehmens transparent und nutzbar.

ZEIT online: Digitaler Arbeitsplatz — Das allumfassende Intranet

Adobe scheitert erneut im Bereich Webdesign

With all the time, effort and money that Adobe spends on creating a “code free” solution for designing websites, you’d think that they would be able to create something decently usable by now. So what’s holding them back? Today we’ll take a brief walk down memory lane, starting all the way back at PageMill, to see if we can discover any reoccurring themes in Adobe’s history with web designers.

Joshua Johnson: Why Adobe Doesn’t Understand Web Designers

Foto: Open Sign von David Lofink (Lizenz: CC-BY)

Da ist es nicht verkehrt, über die Hintergründe Bescheid zu wissen. Das ist nützlich, wenn du irgendwann bei der Fehlerbehebung oder Erweiterung helfen willst, weil deine Software auf der Dritter aufbaut.

Es ist aber auch eine interessante Lektion über Abläufe und Methoden in verteilten Teams, die deiner Karriere auf die Sprünge helfen kann. Denn meist lassen sich Lösungen aus der Community auf die Organisation von Teams in Unternehmen anwenden.

Hier soll es zunächst darum gehen, ein Gefühl für die Arbeitsweisen zu entwickeln, denn:

Wer sich an der Open-Source-Entwicklung beteiligen möchte, tut also gut daran, zunächst einmal die Gepflogenheiten des jeweiligen Projekts kennenzulernen. [via]

Die Frage ist nur: Wo fängst du am besten an?

Beherrsche dein Handwerk

Die Software-Branche hat sich in vielerlei Hinsicht professionalisiert, auch bei den (erfolgreichen) Hobbyprojekten. Also solltest du das auch.

Beherrsche verteilte Versionsverwaltung (Distributed Version Control System, DVCS). Versionsverwaltung an sich ist die Grundlage für jedes Arbeiten an Software — das solltest du verinnerlicht haben wie das Atmen. Verteilte Versionsverwaltung ist speziell auf die Arbeit in Teams zugeschnitten und wird daher in immer mehr Projekten verwendet. Dabei ist unerheblich, für welche Software du dich entscheidest. Mein Favorit ist Git. Andere bevorzugen Mercurial.

Beherrsche die Kunst der testgetriebenen Entwicklung (Test-Driven Development, TDD). Sie macht dich zu einem besseren Programmierer, denn Tests…

• fördern gutes Software-Design
• erhöhen die Wartbarkeit deiner Programme
• geben Dritten einen guten Überblick in den Funktionsumfang

Sowohl der Umgang mit Versionsverwaltung als auch testgetriebene Entwicklung erfordern natürlich viel Übung. Deshalb:

Starte ein Lieblingsprojekt

Die Amerikaner nennen es treffend „pet project“. Andere müssen nicht unbedingt nützlich oder wichtig finden, was du da tust. Es ist dein Projekt, also mach was daraus. Lerne dabei. Probier Dinge aus. Amüsier dich. Beherrsche dein Handwerk.

Ich würde dir wärmstens ein GitHub-Account empfehlen, um dich mit anderen Entwicklern auszutauschen und Code freizugeben, vor allem bei Verwendung der Programmiersprachen Ruby, Python und Javascript (siehe GitHubs Top Languages)

Organisiere und vermarkte dein Projekt. Dabei hilft natürlich auch:

Vernetze dich

Folge den richtigen Leuten. Twitter erfreut sich unter uns Technikern großer Beliebtheit und ist dafür gut geeignet. Es mag vielleicht eine Weile dauern, bis man sein Netzwerk zusammengestellt hat, aber es ist den Aufwand wert.

Besuch User Groups in deiner Umgebung, um persönlichen Kontakt herzustellen und interessante Leute und Projekte zu finden.

Nimm an Konferenzen teil. Dabei ist der Preis nicht unbedingt ein Qualitätskriterium. Manche Community stellt für einen Bruchteil des Preises großartige Veranstaltungen auf die Beine.

Stell dich darauf ein, gewohntes Terrain zu verlassen. Bis vor kurzem habe ich noch nie einen Chat für technische Diskussionen betreten. Mailinglisten sind nicht (mehr) in allen Teilen der Szene gleich populär. Mach deine Mitarbeit nicht davon abhängig, welches Kommunikationsmittel du gern benutzt.

Aber mach deine Mitarbeit davon abhängig, wie du behandelt wirst:

Bleib, wo du willkommen bist

Ich mag Ruby (und Rails) auch deswegen, weil man offen miteinander umgeht und Diskussionen sachlich und auf hohem Niveau geführt werden. Auch wenn so mancher das anders sieht.

Bleib, wo du dich wohlfühlst — denn das ist der Schlüssel zu großartigen Projekten.

Foto: S is for Smoke von Stuart Anthony (Lizenz: CC-BY-NC-ND)

Scrum ist wie eine Beziehung: Du musst dran arbeiten.

Und zwar nicht nur dafür, dass Scrum sein volles Potenzial ausspielt und deinem Team ermöglicht, ihre Arbeitsweise und -ergebnisse kontinuierlich zu verbessern. Sondern auch gegen die Verwässerung des Prozesses von außen.

Damit euer Prozess sich nicht komplett auflöst, achte auf diese Warnsignale:

1. Das Team schreibt die User Stories selbst

Normalerweise sollten die User Stories vom Product Owner geschrieben werden. Dabei kann er durchaus vom Team unterstützt werden, wenn es etwa um Formulierungen geht. Wenn der Product Owner nur noch eine Reihe von Anforderungen bellt und das Ordnen in User Stories dem Team überlässt, stimmt etwas nicht.

2. Die letzte Retrospektive war vor mehreren Monaten

Retrospektiven sind das Mittel der Wahl, um Arbeitsabläufe zu verbessern sowie Produktivität und Zufriedenheit im Teams zu steigern. Manche sagen sogar, Retrospektiven können als Einstieg in die agile Entwicklung genutzt werden.

Fakt ist: Wer längere Zeit keine Retrospektive gemacht hat, läuft Gefahr, sich im Kreis zu drehen.

3. Der Scrum Master wurde abberufen

Scrum Master sorgen für eine störungsfreie Arbeitsatmosphäre des Teams und haben eine vermittelnde Funktion zwischen Team und Product Owner. Teams sollten durch sie nicht nur gegen den Product Owner, sondern auch vor sich selbst geschützt sein.

Für die Rolle des Scrum Masters muss Budget vorhanden sein. Die Rolle darf nicht einfach wegdefiniert werden. Sonst kann man den Prozess eigentlich gleich lassen.

4. Für Schätzungen ist „keine Zeit“

Auch wenn Schätzungen in manchen Augen überbewertet sind, erfüllen sie ihren Zweck: Fortschritt messbar machen und Entscheidungshilfe sein für die nächsten Aufgaben — etwa wenn es darum geht, was bis zu einem Termin noch alles fertig werden kann.

Ohne Schätzungen arbeitet jeder nur vor sich hin, man weiß weder, was zu schaffen ist noch was geschafft wurde.

5. Es gibt keinen Burndown pro Sprint

Der Burndown ist eine grafische Übersicht über den Fortschritt im aktuellen Sprint. Das geht Hand in Hand mit Schätzungen: Ohne Schätzungen kein Burndown. Ohne Burndown kein Indikator, ob die zweite Hälfte des Sprints zu schaffen ist. Ohne diesen Indikator keine Möglichkeit gegenzusteuern. Ohne Gegensteuerung keine Selbstorganisation.

6. Der Product Owner legt fest, dass Sprints nicht abgebrochen werden dürfen

Natürlich darf das Team einen Sprint abbrechen. Und natürlich muss ein triftiger Grund dafür vorliegen (wenn etwa am Tag nach dem Planning klar wird, dass einige Grundannahmen im Planning grundsätzlich falsch waren).

Kein Team bricht mutwillig einen Sprint ab — dafür ist der zeitliche Aufwand viel zu hoch. Dem Team den Abbruch zu verwehren ist ein Eingriff in die Selbstorganisation der Gruppe.

7. Spikes werden zu Produktcode

Spikes sind minimale prototypische Implementationen einer Funktionalität und werden typischerweise zur Evaluation neuer Ideen und Technologien und deren Machbarkeit verwendet.

Solche Programmteile sind häufig nicht von der Qualität, die für ein Produkt in Frage kommt. Leuchtet ja auch ein: Wenn du etwas ausprobierst und damit möglichst schnell zu einer Entscheidung kommen willst, halten Qualitätsansprüche nur auf. Deshalb sollte Programmcode aus Spikes möglichst nicht wiederverwendet, auf keinen Fall aber im Ganzen ins Produkt übernommen werden.

8. Die Vision für das Produkt ist dem Team nicht (im Ganzen) bekannt

Um gute Arbeit zu leisten, muss man gut informiert sein. Bei agiler Softwareentwicklung mag man zwar immer nur für einen kurzen Zeitraum detailliert planen. Aber trotzdem müssen solche Teams zwecks Orientierung die Vision des Produktes immer vor Augen haben.

Fazit

An einer guten Beziehung muss man ständig arbeiten, sonst geht sie kaputt. Ähnlich sieht es mit Scrum aus.

Ich könnte natürlich sagen, dass beides Selbstläufer wären. Aber wir wollen hier doch ehrlich bleiben, oder?

Scrum ist harte Arbeit und Disziplin. Als Team muss man um den Prozess kämpfen, wenn man etwas davon haben will.

Diese Liste lässt sich sicher noch erweitern. Welche sind deine Warnsignale? Woran merkst du, dass du dich um deinen Prozess kümmern musst?

Foto: Old Spanish Lighthouse von Storm Crypt
(Lizenz: CC-BY-NC-ND)

Arbeitsplatz

Michael Lopp, Autor von Being Geek und Managing Humans, stellt ausführlich und unterhaltsam seinen Arbeitsplatz und seine tägliche Routine vor und erklärt, warum er seine Freundin anblaffen muss, wenn sie ihn dort stört:

A Nerd in a Cave

Testgetriebene Entwicklung

Das Thema testgetriebene Entwicklung (test-driven development, TDD) hatte ich schon an anderer Stelle angeschnitten. Die Motivation dahinter, wie das alles zusammenpasst und welchen Einfluss die Methodik auf die Produktivität hat:

I Don’t Have Time for Unit Tests

Programmierer-Kompetenzen

Sich selbst einzuschätzen fällt immer schwer. Diese umfangreiche Übersicht hält einem vor Augen, wie groß das Feld der Softwareentwicklung wirklich ist und hilft dabei, eigene Schwächen zu identifizieren:

Programmer Competency Matrix

Umgang mit schwierigen Charakteren

Wie geht man als neuer Teamleiter mit Menschen um, die in der Vergangenheit aggressiv und unprofessionell auftraten und die Arbeit anderer als die eigene ausgaben? Interessante Fragestellung und einige sehr eindrucksvolle Antworten:

New Team Lead – How to deal with a resentful former peer

Versionsverwaltung, Kommunikation von Veränderungen

Wie schon in meinen Erkenntnissen über Produktentwicklung erwähnt, ist es wichtig darüber nachzudenken, ob man eine Veränderung als inkrementell oder als radikalen Bruch kommuniziert. Beim Wechsel von zentraler zu dezentraler Versionsverwaltung ist nach Meinung von Bill Wagner einiges schiefgelaufen:

Distributed Version Control is a Disruptive Change

Foto: race von telmo32 (Lizenz: CC-BY-ND)

Wenn du dabei bist, die Software so grundlegend umzugestalten, dass kein Stein auf dem anderen bleibt?

Wenn du plötzlich und ungewollt dem ausgesetzt bist, was allgemein als Veränderungsmanagement bezeichnet wird?

Wenn du dir mindestens einmal in der Woche vornimmst, das Pinguin-Prinzip noch einmal zu lesen?

Druck von außen

In unserer konkreten Situation haben wir Entwickler drei „Kunden“:

1. Consultants/Projektentwickler, die mit dem Produkt Projekte umsetzen wollen.
2. Verkäufer, die den Kunden überzeugen wollen, dass das Produkt seine Anforderungen schon von Haus aus optimal abdeckt oder mit geringem Aufwand abdecken wird.
3. Endkunden, die das Projekt bezahlen und einsehen sollten, dass ihre Wünsche auf die zur Verfügung stehende Funktionalität abgebildet werden müssen.

Dabei haben wir mit der ersten viel, mit der zweiten weniger und mit der dritten Gruppe so gut wie keinen direkten Kontakt. Entsprechend verteilt sind die Anfragen, die uns erreichen.

Hier sind meine Erkenntnisse aus den typischen Situationen, die sich daraus ergeben:

Zunächst einmal: Genieß den Augenblick

Produktentwicklung macht großen Spaß — nur selten hat man die Möglichkeit, sich praktisch fortwährend mit neuen Technologien beschäftigen.

Ausprobieren, evaluieren, umsetzen. So manches auf der grünen Wiese anfangen. Der Traum all jener Entwickler, die in den technischen Vorgaben von Kunden gefangen sind und zum Teil mit uralter Technik moderne Anforderungen umzusetzen versuchen. (Haltet durch, Jungs!)

Diese Arbeitsweise ist purer Luxus. Das sollte man unbedingt zu schätzen wissen.

Halte den Wissens-Vorsprung klein

Erkläre den anderen, warum Änderungen notwendig sind. Welchen Nutzen sie bringen. Stell dich darauf ein, das immer wieder erklären zu müssen.

Diese Kommunikation nach außen ist eine echte Gratwanderung. In technische Details zu verfallen kann genauso ins Auge gehen wie immer nur zu behaupten, es werde alles gut.

Achte darauf, das große Ganze dahinter richtig zu verkaufen: Um die gewünschte Adaption zu erwirken, müssen manche Ideen als radikaler Bruch vermarktet werden — auch wenn man im ersten Moment meint, dass kleine Änderungen besser verdaut werden können.

Teile deine Werkzeuge, Lösungen Erkenntnisse und Arbeitsweisen mit den anderen und schotte dich nicht ab. Nimm dir die Zeit, zwischendurch den aktuellen Stand oder kleine Nebenprodukte zu präsentieren.

Bekämpf die Gerüchte von Anfang an

Wer nicht in die Entwicklung involviert ist, neigt dazu, Annahmen auf Basis seiner Kenntnisse zu treffen.

So entstehen Gerüchte: Stimmt es, dass Feature X abgekündigt wird? Das wäre alles viel schneller gegangen, wenn… Und überhaupt — warum kümmert ihr euch nicht erstmal um die wichtigen Dinge?

Es ist unglaublich schwierig, Entscheidungen später zu rechtfertigen als andere früh darauf vorzubereiten und mitzunehmen. Wehe, wenn dann noch eine Sache nicht läuft wie geschmiert!

Hinterher ist bekanntlich, wenn man’s vorher gewusst hat.

Erschwerend kommt hinzu, dass man sich als Produktentwickler viel zu schnell an den Zustand gewöhnt hat, dass viele Dinge kaputt sind, deaktiviert oder gelöscht werden.

Wenn du das falsch kommunizierst, ist das guter Nährboden für weitere Gerüchte.

Sieh dich auch mal um

Auch wenn Umsetzung und Kommunikation nach außen einen Großteil des Tagesgeschäfts ausmachen — vergiss nicht, dass Feedback aus den Projekten überlebenswichtig für ein gutes Produkt ist.

Halt also die Ohren offen. Welche Lösungen sind im Einsatz? Was muss verbessert werden? Was wird gebraucht? Und viel wichtiger: Was kann wegfallen?

Gerade dieser letzte Punkt ist selten offensichtlich und wird oft nur zwischen den Zeilen erwähnt. Features zu streichen erfordert Mut auf der einen und Einsicht auf der anderen Seite.

Finde dein Tempo

Und zwischen all dem ist Software-Wartung vielleicht noch ein Thema.

Einfach mal einen ganzen Tag nur den Blick nach vorne richten? Vergiss es. Kontextwechsel sind an der Tagesordnung, wenn du dich auch noch um die aktuelle Version des Produkts kümmern, Fragen beantworten und Probleme untersuchen musst.

Daher ist es ratsam, sein eigenes Tempo zu finden, Anfragen zurückzustellen und stapelweise abzuarbeiten. Finde heraus, was für dich am besten passt, ohne die anderen vor den Kopf zu stoßen.

Kommunikation ist das A und O bei großen Veränderungen. Nimm die anderen mit.

Sonst haben sie schon keine Lust mehr, bevor ihr überhaupt fertig werdet.

Foto: Gimme a V von hjhipster (Lizenz: CC-BY-NC)

Softwarevertrieb

Kaum zu glauben, aber wahr — in meinen drei Jahren als Vollzeit-Entwickler habe ich bisher weniger über den Vertrieb von Unternehmenssoftware gelernt als durch diese vierteilige Serie:

The very most basic things your company needs to know about sales

Merkmale erfolgreicher IT-Ingenieure

Du weißt schnell, wenn du einen vor dir hast. Aber was genau macht einen erfolgreichen Software-Ingenieur aus?

Top Three Traits of Successful Engineers

Interfacedesign

„Sollen wir den Button unten oder oben platzieren?“ — „Mach eine Option draus!“ Anpassbarkeit von Elementen ist nicht immer die beste Wahl:

The Pitfall of Customizability in UI Design

Flamewars

Wenn es um Tools geht, sind in der Softwarebranche die Fronten schnell verhärtet — Linux gegen Mac gegen Windows, die ewige Editor-Diskussion, oder auch das Thema Versionsverwaltung. Um dem wiederkehrenden „Murmeltiertag“ ein Ende zu setzen, hat Benjamin Pollack einen Vorschlag:

Make Love, Not Flamewars

Schätzungen

Schätzungen sind ein Problemkind unserer Branche und mit ein Grund, warum agile Methoden wie Scrum so schnell populär geworden sind. Warum es nicht gut ist, Schätzungen zu viel Bedeutung zu geben:

Estimates are overrated

Charles Darwin im Alter von 71 Jahren (Lizenz: gemeinfrei)

Das war 1844, eineinhalb Jahrzehnte vor der Veröffentlichung seines Hauptwerks Die Entstehung der Arten. Er war dabei, mit seinen Beiträgen zur Evolutionstheorie alles auf den Kopf zu stellen.

Heute erscheint die These weit weniger radikal als noch bei der Veröffentlichung: Arten verändern sich, um sich besser an die Umwelt anzupassen.

Dabei bleiben vorteilhafte Variationen erhalten.

Evolution in der Softwareentwicklung

Genau diese Grundannahmen der Evolution machen sich Softwareentwickler heute zunutze.

Bei der evolutionären Entwicklung wird zunächst nur eine Anwendung mit den Grundfunktionalitäten bereitgestellt. Dann wird nach und nach erweitert — entsprechend des Feedbacks vom Kunden.

Natürlich ist dabei der Entwickler die treibende Kraft, im Gegensatz zu Darwins natürlicher Selektion. Software entwickelt sich nicht von allein weiter.

Deshalb ist auch das Prinzip des Gradualismus, also Änderungen in vielen Zwischenschritten, nicht gegeben. Es ist aber Voraussetzung für eine erfolgreiche Evolution des Systems und sollte Ziel der Weiterentwicklung sein.

Paradebeispiel Open Source Software

Open Source Software wird ja praktisch nur evolutionär entwickelt.

Linus Torvalds hat sich vor 20 Jahren nicht hingesetzt und geplant, Linux in einem guten Jahrzehnt auf den Großteil der Server zu bringen und es zu einer wirtschaftlichen Größe zu etablieren.

Typischerweise entstehen ja Open-Source-Projekte so, dass jemand ein ganz spezielles Problem für sich selbst löst. Mit ein bisschen Glück findet man Mitstreiter, die neue Funktionalität dazu- oder vorhandene entsprechend ihrer eigenen Wünsche umbauen.

Die Software evolviert über die Zeit.

Gern wird auch mal zu drastischen Mitteln gegriffen, um ein Projekt voranzutreiben. Aus der durchaus lesenswerten Erklärung, warum einige Entwickler aus der Community um das Projektmanagement-Tool Redmine es für sinnvoll erachteten, das ChiliProject abzuspalten:

However, in the view of some of Redmine’s leading developers, the maintenance and evolution of Redmine has not been as predictable and responsive as its developer community is capable of […] A group of developers from the Redmine community has therefore concluded that the only way to ensure continued, sustained and stable development of our favorite project management solution is to fork it.

In Darwins Augen ist hier also eine neue Art entstanden.

Flexibilität und Wartbarkeit sichern: Evolution statt Sackgasse

Um evolutionäre Entwicklung zu fördern und Software später an veränderte Bedingungen anpassen zu können, müssen Programme flexibel gehalten werden. Sonst drohen irgendwann teure Neuentwicklungen.

Das schafft man nur, wenn regelmäßig aufgeräumt und dem Verfall rechtzeitig vorgebeugt wird.

Dann ist man auch in der Lage, agil zu entwickeln.

Vorbei die Zeit, in der Softwareprodukte in jahrelangen Prozessen am Kunden vorbei spezifiziert und umgesetzt wurden. Die Vorstellung, heute schon wissen zu können, welche Detailfunktion der Kunde in ein paar Jahren braucht, muss einem da zwangsläufig wie Schöpfungsbiologie vorkommen.

Zusammenfassung

Darwin zögerte damals, die Theorie zu veröffentlichen. Seine ursprüngliche Auffassung war die Unveränderlichkeit der Arten gewesen, aber seine und die Recherchen anderer widerlegten die These. Und er war sich der Tragweite seiner Entdeckungen bewusst.

Sein Hauptwerk schloss er mit dem Satz:

Es ist wahrlich etwas Erhabenes um die Auffassung, [dass] aus einem so schlichten Anfang eine unendliche Zahl der schönsten und wunderbarsten Formen entstand und noch weiter entsteht.

Diese Feststellung lässt sich so sogar auf Software übertragen.

Hast du schon Erfahrung mit evolutionärer Entwicklung gesammelt? Sag’s uns in den Kommentaren!