Buchempfehlung: Agile Retrospectives

Lese gerade das Buch Agile Retrospectives aus der Pragmatic Programmers Reihe. Sehr zu empfehlen.

Gedanken zu Nassim Talebs Antifragilität und Software-Architektur

Interessanter Artikel vom praktizierenden Agile Coach Gerrit Beine der Nassim Talebs Konzept der Antifragilität und Russ Miles Vergleich von Antifragilität und Microservices reflektiert.

Andere Links:

• Wir brauchen mehr Chaos - Rolf Dobelli (Die Zeit) im Gespräch mit Nassim Taleb


• "Antifragilität" von Nassim Taleb: Größenwahnsinnig und toll - Rezension von Jan Füchtjohann

Companies Need to Change How They Change (Chef Blog)

I could not agree more: Companies Need to Change How They Change (Chef Blog)

Buchempfehlung: Behind Closed Doors

"Das Buch Behind Closed Doors von Johanna Rothman und Esther Derby erinnert entfernt an Tom DeMarcos Der Termin. Es ist kein klassisches Fachbuch, sondern der Leser begleitet Sam, einen neuen Manager in einer Softarefirma, während seiner ersten sieben Wochen. Jede dieser sieben Wochen entspricht dabei einem Kapitel."

Erste Hilfe für scheintote Retrospektiven

In "Erste Hilfe für scheintote Retrospektiven" schreibt Stephan Zimmermann von der Andrä.ag wie sie ihre Retrospektiven wiederbelebt haben.

Andere agile Blogs die oft wertvolle Beiträge veröffentlichen und die ich gerne verfolge:

• it-agile Blogplanet
• bor!sgloger
• Gerrit Beine
• Succeeding with Agile - Mike Cohn's Blog

Developer Economics Q1 2014

Vision Mobile hat gerade den Developer Economics Report für das 1. Quartal 2014 veröffentlicht. Er ist dort zum freien Download verfügbar. Wer sich nicht extra registrieren lassen möchte, findet den Bericht hier im Blog (VisionMobile-Developer_Economics_Q1_20141).

Ist keine ganz leichte Kost. Da muss man sich schon ein wenig Zeit für nehmen. Die wichtigsten Schlussfolgerungen sind aber immer am Seitenrand zusammengefasst.

Die Übersicht aller veröffentlichten Berichte findet sich hier, viele davon frei.

Tip: TED Talks

Wer es noch nicht kennt: Die TED ist eine großartige Innovationskonferenz. Die besten Vorträge werden frei ins Netz gestellt und sind z.B. über den TED Talks YouTube Channel oder direkt über die TED Talks-Seite verfügbar. Das Spektrum ist breit, die Vorträge sind mäßig lang (5-8 min.) und immer ausgezeichnet vorbereitet und präsentiert. Für unterwegs gibt es auch die TED Talks App.

Hier ein paar Vorträge die ich kürzlich ganz hervorragend fand:

• Yves Morieux: As work gets more complex, 6 rules to simplify
• Ryan Holladay: To hear this music you have to be there. Literally
• Sally Kohn: Let’s try emotional correctness

"Qualitätsinvestition statt technischer Schulden"

Martin hat mich auf den sehr interessanten, bei Heise Developer veröffentlichten Artikel Qualitätsinvention statt technischer Schulden aufmerksam gemacht.

Surrogates (alpha) - iPad on wheels?

(Aus HackerNews): Der schwedische Kanban-Guru Henrik Kniberg hat versuchsweise mit einem mobilem iPad an einer Stockholmer Konferenz teilgenommen während er selbst in Thailand weilte:

Henrik Kniberg geht der Saft aus: "Hat irgendjemand ein Ladegerät?"

Das Search-Server-Duell: Solr oder ElasticSearch

Ein sehr informativer Vergleich von Solr und ElasticSearch in Form eines virtuellen Streitegespräch: Apache Solr und ElasticSearch im Streitgespräch.

"No Experience Required!"

Der Blogpost No Experience Required! stellt die Ergebnisse von empirischen Studien zusammen die insgesamt über 30 Jahre abdecken. Erstaunliches Ergebnis: Es konnte absolut gar keine Korrelation zwischen der Erfahrenheit eines Programmierers (in Jahren) und der von ihm produzierten Codequalität festgestellt werden. Das stimmt nachdenklich, oder?

Code Inspection is not optional!

Im Blog Accelerated Development gibt Dalip Mahal mit Inspections are not Optional eine sehr schöne Motivation um Anforderungsdefiziten mit Code Inspection zu begegnen. Fazit: Je später die Inspektion desto teurer, d.h. es ist ratsam diese so früh wie möglich im Entwicklungsprozess einzuplanen. Ja genau: Idealerweise ganz an den Anfang.

Technology Radar

Hosted on Martin Fowlers own Thoughtworks Advisory Board. Worum gehts?

The ThoughtWorks Technology Advisory Board is a group of senior technology leaders within ThoughtWorks. They produce the ThoughtWorks Technology Radar to help decision makers understand emerging technologies and trends that affect the market today. This group meets regularly to discuss the global technology strategy for ThoughtWorks and the technology trends that significantly impact our industry.

New Programming Jargon:"Reptile Code"

With New Programming Jargon Jeff Atwood added all the modern programming metaphors to the  Jargon File. With Reptile Code i would like to propose one myself.

In "The Science of Discworld (1)" [1], chapter Mammals on the Make, biologist Jack Cohen elaborates on of one of science's remarkable misjudgments. At this time, the concept of DNA was often referred to as Blueprint of life. And it still is today:

It seemed to be a natural conclusion to approximate a species' level of evolution or its complexity by the length of its DNA strand, i.e. the longer the DNA code the more sophisticated the species.

This intuitively made sense. By analogy, the engineering blueprint of Jumbo Jet is a lot longer than that of a simple paraglider.

The embarassing result: Empirically, the DNA of a frog is much longer than the human DNA. Confusion took hold. Could it be that God considered simple reptiles higher than his flagship creation, man?

Later, it was found that human DNA is so much shorter because it is organized better [2].
Put simply, frog DNA contains a variety of contingency plans for environmental changes that accumulated in the course of evolution as lots of code patchwork. For instance,

if temperature between -14° und -7° do this,
else if between -7° and 0° do that,
else if ... etc.

Warmbloods like man escape this complexity through the elegant statement

set internal temperature to 36°.

Especially for developers, i find this view very accessible, because they very well know about metrics like Lines of Code (LoC) oder Cyclomatic Complexity (McCabe) from their own experience [3].

Hitting such code, you could probably say in Mr.Spock voice:

Fascinating! This component is likely to be hard to maintain: The average cyclomatic complexity of their methods differ with 57.63 significantly from that of the World Code Health Organization (WCHO) which recommended a maximum 20.

Compared to Mr. Spock just stating

Woah! Reptile Code!

really hits home and feels more natural.

Footnotes:

1. As a teenager i loved reading Terry Prattchet Discworld-novels, especially the series Science of Discworld which were written together with co-authors Ian Stewart und Jack Cohen and which uniquely prescribes the wonderful cosmology of Roundworld and is amongst the best introductory works on evolution after Richard Dawkins.


2. Later, it turned out that DNA-Code at times can "reorganize" and shift to a whole new organizational level of abstraction. It seems, evolution knows the concept of "refactoring" but she is a lot more cautious on eliminating "dead code" (perhaps of the deep coupling of SCM and the code itself).


3. In general, long codes with a high McCabe-Complexity are a lot harder to maintaint, cf.:
   
   
   
   • Halstead-Metrik
   • Lines of Code (LoC)
   • McCabe-Metrik
   • Function-Points

Links:

• DNA Reorganization, The Science of Disc World, p. 324 ff.
• The Science of Disc World [YouTube]

Hanselman about Portable Class Libraries

Scott Hanselman über Portable Class Libraries.

What's in a Good Commit?

Repost The Morning Brew:

What's in a good commit? & What's in a good commit? - Timo Mihaljov and Jaco Pretorius discuss best practices for what should go in a commit when developing, with Timo giving the initial list of 5 best practices and Jaco responding to these sharing his opinions.

Lesenswert.

There's only one rule when it comes to committing commented-out code ;-)

Buchempfehlung: REST in Practice

Eine praktische Einführung in REST. Wärmstens empfohlen.

• offizielle Website
• Amazon

How to get (coding) standards wrong

Erik Dietrich fasst in How We Get Coding Standards Wrong typische Anti-Patterns bei der Standardisierung zusammen.

Buchempfehlung: The connected company

Bin über den Veranstaltungshinweis: "Softwarekompetenz für die Zukunft" (heise developer) auf das Buch The connected company gestoßen. Aus der Kurzbeschreibung:

The future of work is already here. Customers are adopting disruptive technologies faster than your company can adapt. When your customers are delighted, they can amplify your message in ways that were never before possible. But when your company's performance runs short of what you've promised, customers can seize control of your brand message, spreading their disappointment and frustration faster than you can keep up.