Maximize the number of characters you type?

Over the last months and years I have advised many teams and organizations and found a pattern again and again.

We talk about how a software development team doesn’t get better by typing more characters on the keyboard. Usually the participants in the workshops laugh at this statement because it’s absurd. Software doesn’t get any better only if we type more characters.

It gets quiet when I ask why they try to maximize the number of features built.

Sometimes there is a very good discussion afterwards, sometimes…

Entscheidungen – schneller

Gestern ist via Twitter bei mir der offene Brief von Jeff Bezos an die Aktionäre von Amazon hereingeflattert. Er passt sehr gut in ein paar Beobachtungen die ich ebenfalls gemacht habe. Eine Dieser ist, dass es grösseren Unternehmen sehr schwer fällt schneller die richtigen Entscheidungen zu fällen. In einer Welt die sich immer schneller bewegt, wird dies aber immer mehr zu einem Erfolgsfaktor. Jeff nennt dies “High-Velocity Decision Making” und erläutert dazu vier Gedanken:

“…never use a one-size-fits-all decision-making process…”
“…most decisions should probably be made with somewhere around 70% of the information you wish you had…”
“…use the phrase ‘disagree and commit’…” ( das werden wir wohl in nächster Zeit sehr oft höhen )
“…recognize true misalignment issues early and escalate them immediately…”

In der agilen Welt reden wir oft von Feedback-Cycle, hier geht es also um die Verkürzung des Decision-Making-Cycle als Teil des Feedback-Cycle, denn auch Jeff ist der Meinung, dass “customer focus” eine Firma vital hält. Continue reading “Entscheidungen – schneller” →

Hypothesis-Driven Development

tl;dr

Ein gutes Werkzeug um Personen und Organisationen in der Softwareentwicklung (Teams, Management, etc) effektiver zu machen, ist sich auf die Dinge zu konzentrieren, die am meisten Wert für den Kunden haben. Um schnell Feedback zu bekommen etabliert man Continuous Delivery und damit man besser mit Unsicherheit umgehen kann hilft Hypothesis-Driven Development.

Man formuliert die Hypothesen nach folgendem Muster (Siehe auch: Quellen unten):

Wir glauben das <wenn wir diese Funktion bauen>
für <diese Personen>
liefert es <dieses Ergebnis>
Wir haben das Vertrauen fortzufahren, wenn wir (bis <Datum>) folgendes <messbare Signal sehen>.

Continue reading “Hypothesis-Driven Development” →

Gradle wartet auf Service in Docker Container

Im Zusammenhang mit automatisierten Applikationstest war in einem späteren Schritt einer Deployment Pipeline eine Applikation in einer Testumgebung zu starten, um danach JUnit-Tests auszuführen. Die Applikation war eine Spring Boot Applikation innerhalb eines Docker Containers. Als Build Tool kam Gradle zum Einsatz. Wenn man nun mit Docker den Container startet, dann beendet das Docker CLI sofort nachdem es den Java-Prozess innerhalb des Containers gestartet hat. Will man nun sofort mit den Tests beginnen, dann ist die Spring Boot Applikation aber eventuell noch nicht vollständig gestartet und die Tests schlagen fehl. Continue reading “Gradle wartet auf Service in Docker Container” →

Test-Säulen und Test-Treppe (Test-Pillars and Test-Stairs)

Wer sich mit Continuous Delivery und Testen auseinandersetzt kommt früher oder später an der Testpyramide vorbei. Die Mehrheit aller Tests sind Unit Test’s, darauf aufbauend wird auf Stufe Komponenten oder Services getestet und ganz oben auf der Pyramide wird die Gesamtheit des Systems getestet. Nach oben wird die Anzahl der Tests kleiner.

In diesem Artikel möchte ich einen Weg beschreiben, bei dem die Tests der oberen Stufen auch in den Tests der unteren Stufen ausgeführt werden und um weitere Tests auf jeder Stufe ergänzt werden. Das Ergebnis ist eher eine Stufenpyramide und das Vorgehen führt erstaunlich einfach an Domain Driven Design heran. Continue reading “Test-Säulen und Test-Treppe (Test-Pillars and Test-Stairs)” →

Wie schnell bringt mein Unternehmen eine index.html Seite in die Produktion? (The Zero Dev Walk)

DevOps und Cross Functional Teams sind in aller Munde und wer es noch nicht kennt, dem sei das Buch “The Phoenix Project” von Gene Kim, Kevin Behr und George Spafford sehr empfohlen. Wie aber bekommt man aber nun ganz konkret heraus was zu tun ist? Was sind die konkreten Schritte, die gemacht werden müssen, damit eine DevOps Kultur entsteht? Continue reading “Wie schnell bringt mein Unternehmen eine index.html Seite in die Produktion? (The Zero Dev Walk)” →

Docker 1.9.1 hängt mit Docker Toolbox auf Windows

diese Woche ist das Problem aufgetreten, dass auf den Entwicklerrechnern Docker Container einfach hängen geblieben sind und nicht mehr reagiert haben. Die Umgebung war ein Windows® 7 Prof mit Docker Toolbox. Der Fehler trat beim Starten einer docker-compose Konfiguration mit 4 Containern (zwei JBoss, zwei PostgreSQL) auf. Auch ein docker-compose stop oder rm -f war bei dem hängenden Container nicht mehr möglich. Windows zeigte an, dass ein Prozessor bei 100% ausgelastet ist.

Bei einigen Entwicklern hat es funktioniert, bei anderen nicht. Wie sich herausstellte, war bei Ersteren die Version 1.9.0 der Toolbox installiert, bei denen Zweiten eine Version 1.9.1.

Nach der Analyse des Problems, habe ich dann den Issue #18180 gefunden. Dort sind diverse Vorschläge dokumentiert, wie man das Problem lösen kann. In unserem Fall hat es geholfen den storage driver von docker engine auf overlay zu ändern. Wir haben dazu das Script (start.sh) hinter Docker Quickstart angepasst und bei der Erzeugung des Virtualbox Images mit dem Namen “default” noch folgenden Parameter angegeben:

... --engine-storage-driver overlay ...

Dies kann man aber auch direkt auf der Konsole machen, indem man die alte Maschine erst löscht und dann neu mit dem Treiber overlay anlegt:

docker-machine rm default
docker-machine create -d virtualbox --engine-storage-driver overlay default

Podcast List

When I run, I hear podcasts. Here is my actual list. Any suggestions are very welcome 🙂

Veränderungen

in letzter Zeit gab es bei mir einige Veränderungen. Angefangen hat es damit, dass ich überlegt habe, was ich wohl in nächster Zeit gern machen würde.

Über die Jahre habe ich von Programmierung, über Projektmanagement und Teamleitung bis hin zur Infrastruktur in vielen Bereich gearbeitet, mich weitergebildet und Erfahrungen gesammelt. Mich interessiert die Softwareentwicklung und ich bin froh, diesem Interesse auch beruflich nachgehen zu können. Insbesondere faszinieren mich die kleinen Dinge. Bausteine die je nach Problemstellung flexibel zusammengesetzt werden können Dazu gehören natürlich die Grundlagen der Softwareentwicklung (Test Driven Development, Software Craftsmanship) auch moderne methodische Ansätze (agile, lean, Domain Driven Design, Continuous Delivery), kleine Tools (vert.x, Ratpack, Spring Boot, Gradle – ich benutze meist Java/JVM) und offene Herangehensweisen. Im Kern geht es mir darum, die Geschwindigkeit bei der Umsetzung zu erhöhen, ohne das wirklich Stress entsteht. Deshalb halte ich den Zeitpunkt für wichtig, wann etwas gemacht wird. Auch schnelle Iterationen über Ideen und nicht erst über die Umsetzung halte ich für zielführend. Damit verbunden ist eine enge Zusammenarbeit von Fachbereich, Entwicklungsabteilung und möglichst auch des Benutzers. Die schnelle Verifikation dieser Ideen ist wichtig – möglichst im Tagesrhythmus, wenn nicht gar schneller – um den wirklichen Nutzen eines Produktes zu finden. Interdisziplinäre Teams (Business/Development/Operating/QA – vielleicht BusDevOps 🙂 ) sind dafür äusserst hilfreich.

Seit einigen Jahren halte ich nun Vorträge (Docker, Microservices, Component Management) und gebe Workshops (Coderetreat, Continuous Delivery). Ich engagiere mich in der Entwicklergemeinschaft und bin Präsident der Java User Group Switzerland geworden. Meine Frau und ich haben zusammen die Weiterbildungstagung “Open Source an Schulen 2015” organisiert. Zusammen mit Geza (aka @infinitary) bereite ich den SoCraTes Day Switzerland vor.

Der grösste Schritt war aber sicherlich, mich selbstständig zu machen: 2015 habe ich die Nautsch Gmbh gegründet. Wir sind interessiert an Kunden, die mit uns in einem partnerschaftlichen Verhältnis an Lösungen erarbeiten möchten und dabei an neuen Sichtweisen interessiert sind. Die Grösse des Unternehmens spielt eine untergeordnete Rolle. Ich persönlich habe Erfahrungen sowohl im Start-Up Umfeld als auch in sehr grossen Unternehmen gesammelt. Wenn Sie also einen Partner für die Umsetzung einer Idee suchen, intern ein Team aufbauen wollen und einen Trainer suchen, oder einfach technische Unterstützung benötigen, helfe ich gern weiter! Sie erreichen mich am besten per E-Mail:

info@nautsch.com