≡ Menu

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

{ 0 comments }

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.

{ 3 comments }

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

Mehr oder weniger zufällig bin ich auf eine Bewegung gestoßen, die Entwicklung (Development) und Administration (Operations) näher zusammenbringen will und damit glänzend zu meiner aktuellen Tätigkeit passt: DevOps.

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!

{ 37 comments }

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

5 lesenswerte Artikel zu unterschiedlichen Themen aus der Softwarebranche:

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

{ 0 comments }

Grundkurs Open-Source-Entwicklung

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

Open-Source-Software hat sich aus der Nische befreit und zu einem ernstzunehmenenden Wirtschaftsfaktor entwickelt. Als Entwickler wirst du früher oder später mit quelloffener Software zu tun haben.

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.

{ 0 comments }

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?

{ 2 comments }

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

5 lesenswerte Artikel zu unterschiedlichen Themen aus der Softwarebranche:

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

{ 1 comment }