This entry is part 7 of 7 in the series OOP 2014 Report

At OOP 2014, Martin Fowler gave the final keynote, broadly called „Software Design in the 21st Century“. He delivered his keynote in two parts, „Workflows of Refactoring“ and „Not just code monkeys“. An infodeck for the first part is available online, so I won’t cover it here.

Frustration with Agile

Martin Fowler expressed his frustration with Agile. He observes that often programmers are dropped user stories onto them to turn them into code. But the Agile Manifesto talks about conversational stories, that Users/Analysts and Coders have conversations about what to build. He demands developers building domain knowledge (and I agree with him), with a reference to „Observed Requirement„.

Responsibility

Being part of those conversations brings responsibility to developers. As an example, Fowler referred to darkpatterns.org:

A Dark Pattern is a type of user interface that appears to have been carefully crafted to trick users into doing things, such as buying insurance with their purchase or signing up for recurring bills.

Someone have build those user interfaces. So Martin asked devs for „impact judgement“: question „which impact has the software on the users, which impact have the users to the world?“.

Not just code monkeys

Martin Fowler identified two areas of our impact as a developer:

  1. Privacy
  2. Alienating Athmosphere

There is a video on youtube that shows the rest of the keynote. I encourage you to watch it (it’s about 6 minutes).

Martin  Fowler ended with strong words:

Change the world and make it better

I was really surprised by this strong statement and I think most of the audience was. It made a strong impression on me.

Here is another account on the keynote (in German).

This entry is part 6 of 7 in the series OOP 2014 Report

Ich habe die Notizen und Anmerkungen zu den Vorträgen, die ich an meinem zweiten Tag auf der OOP 2014 besucht habe, bereits in eigenen Blog-Posts verarbeitet:

  1. Software-Evolution mit aim42 – Architecture Improvement Method
  2. How to improve Estimates for Software: The #NoEstimates view
  3. Imposing Rule-Based Architecture on Legacy Systems
  4. Gehirnwäsche für Führungskräfte

Zu den Vorträgen am dritten Tag:

Value Validated Architecture: Discover Your Architecture sans BDUF (Steve Holyer)

Steve Hoyler fragt, ob der Build/Measure/Learn Zyklus auch für Architektur funktionieren kann. Er stellt ein Vorgehen vor, dass versucht, die Architektur bzw. Architekturentscheidungen mit business value zu untersetzen.

Der Anfang klang ganz vielversprechend: brainstorming darüber, was überhaupt zur Architektur gehört. Dies erzeugt einen offenen Dialog und ein geteiltes Verständnis der Beteiligten. Er sprach über Constraints vs. Options und die Frage, welche Constraints Commitments und welche Options sind.

Dann verlor sich Steve etwas in seinem Vortrag. Das muss er noch ausbauen. Insofern am Schluß etwas enttäuschend. Folien gibt es online.

Architekt zu werden scheint nicht schwer, Architekt zu sein dagegen sehr (Michael Stal)

Hier ging es vornehmlich um eine Art Ausbildung zum Software-Architekten mit Beispielen von der Firma Siemens, die da anscheinden sehr viel Zeit und Kapital investieren.

Wie sieht der Weg aus?

  1. Profiling: welches Wissen brauche ich?
  2. Reflection: welche Lücken habe ich?
  3. Doing: Lücken schließen

Architecture 201x (Stefan Tilkov)

Mit dem Untertitel „Lessons learned from modern web-based systems for Enterprise IT“ (Slides).

Stefan Tilkov hinterfragt alte Annahmen und stellt drei Thesen für eine Architecture 201x auf:

  1. Dinge klein schneiden
    • kleine, fokussierte Apps, siehe auch z.B. 12factor app
    • Isolation + Unabhängigkeit
    • Polyglote Programmierung möglich
  2. Teile integrieren, um ein Ganzes zu formen
    • Robuste System auf unzuverlässigen Netzwerken
    • Referenz auf „Circuit Braker„-Pattern aus dem „Release It!“ Buch mit Hinweis Hysterix und Finagle-Frameworks
  3. Effizienter Betrieb
    • Virtualisiertes OS als Container
    • automatisches Deployment
    • „You build it, you run it“

Wie immer von Stefan Tilkov ein guter Vortrag.

Keynote: Software Design in the 21st Century (Martin Fowler)

Siehe separaten Beitrag.

Komplexität oder Unffähigkeit (Gunter Dueck)

Ich kannte Dueck noch nicht. Ex-Querdenker bei IBM, jetzt im Ruhestand und Vortragsredner. Einfach mal auf Youtube schauen. Zum Beispiel das hier, ab ca. Stunde 1. (den Vortrag von der OOP2014 gibts anscheinend nicht online, war recht lustig).

This entry is part 4 of 7 in the series OOP 2014 Report

This was the title of a talk by Michael Feathers (@mfeathers) at the OOP 2014 conference. I was looking forward to his talk because I like his book „Working effectively with Legacy Code“. In his talk he said that this book is about „bringing automated test in place“. I think that is a good summary.

After looking at various definitions of software architecture, he cited Kent Beck: „If you can’t explain your system using four objects you don’t have an architecture.“ This means you have a small set of things to think about and it makes a system understandable. Michael suggests a practice to tell the story of a system using four (or so) objects. I think I’ll make a blog post explaining the system I am working on in about four objects.

As an example of an architectural rule Michael mentioned the seperation of business logic and persistence.

He presented the following rule-based techniques.

Build checks. At build time check certain rules, can be as simple as grepping source code, i.e. using database code in web modules and failing the build. The problem is that people will find ways around these checks when in a hurry.

Dealing with corruption

Local tagging. (aka „TODO“) code comments that are grep-able

Component tender. someone who (temporary) „takes care“ of a component, i.e. watches and fights architecture or design degradation.

Silent alarms. like build checks but will not break the build

Progress

For making progress you can either fix things („Active Reduction Work“) or just stop making things worse („Thresholded Practice change“).Either way, things will get better.

As a direction for „better“: make the system simple.

His advice do not depend on a particular product. He mentioned „grep“ which is rather low level. In the Java ecosystem, I would mention SonarQube as a monitoring tool for architectural measurements. You can use JDepend with JUnit for implementing build checks.

This entry is part 3 of 7 in the series OOP 2014 Report

At the OOP 2014 conference, Vasco Duarte (@duarte_vasco) gave a talk on #NoEstimates. I heard the term before and I was curious. So I went to the talk.

He said the question is „How can you predict the release date of your project without estimates?“. Vasco argues that to commit to an estimate is to commit to a plan. But with #NoEstimates, one would commit to customer value rather than to following a plan. Another aspect is that estimates are often political and that they often encourage to push „for more“.

One precondition for applying #NoEstimates is to have a stable software development process. That means that for the last 3 or 5 sprints, the number of delivered stories are within certain limits (= velocity stability). This implies that you have rather short sprints. If your „sprints“ are actually mid-range runs (like 2 months), you only know after about half a year whether your velocity is stable.

With #NoEstimates apply the following steps:

  1. Select most important piece of work
  2. Break it down into risk neutral chunks of work (chunks are small, like one person day)
  3. Develope each piece of work
  4. Iterate and refactor

So how do you answer the question for the release date? If you know the number of stories that are needed to implement and you assume that your process remains stable then you can simply extrapolate how many sprints you are going need and hence when you are going to release. Take the average of your historical data and project it into the future.

To me, this is a no-brainer. If you have historical data and a stable process then you don’t have to estimate, you can simple extrapolate from historical data.

To me, #NoEstimates has a number of important preconditions:

  • sprints are short
  • velocity is stable and is likely to remain stable
  • probably, stories should be about the same size

One interesting aspect was that the number of stories seems to be a better indicator for release date than story points. Vasco showed data from several projects to support that.

As I said, if the preconditions are met, this is a no-brainer. It is like driving on the highway at about 130 km/h for the last 15 minutes (stable process). Then we will arrive at our destination that is 130 km away in 1 hour. No need to estimate, simply extrapolate.

Vasco picked on Steve McConnells book „Software Estimation: Demystifying the Black Art“ because McConnell would show that estimates are often poor and he’d recommend „better estimates“ (instead of „NoEstimates“). Having read that book myself I think this was unfair but I will leave this for another blog post.

The talk was interesting and now I know what #NoEstimates is about.

On a side note, I was reminded of the talk „Predictability and Measurement in Kanban“ by David Anderson. If I remember correctly, predictability in Andersons talk relates to system stability in Vascos talk.

This entry is part 2 of 7 in the series OOP 2014 Report

Auf der OOP2014 starteten Stefan Tilkov und Gernot Starkeaim42“ – die Architecture Improvement Method.

Viele Teams, die eine Software über einen längeren Zeitraum, sehen den Bedarf für (technische) Verbesserungen, um die Qualität und die Wartbarkeit der Software zu erhöhen. Das Problem dabei ist, das Management davon zu überzeugen, die nötigen Aufwände zu investieren. Die Nachricht hier ist, dass Änderungen am System durch Geld motiviert sind, d. h. man nicht mit Qualitätsverbesserung oder Professionalität argumentieren sollte.

aim42 soll helfen, die nötigen Verbesserungen zu finden, zu bewerten (möglichst in Geld) und umzusetzen. Dabei soll die „42“ an „arc42“ erinnern, eine Plattform für freie Resourcen für Software-Architekten. Aim42 ist ein offener, Community getriebener Ansatz.

Die drei Phasen von aim42 sind (Zitat):

Die drei Phasen von aim42

  • analyze – find problems, risks, deficiencies and technical debt within your system and your development process
  • evaluate – understand root-causes of problems, determine „value“ of
    problems, issues and their remedies, prioritize
  • improve – systematically improve code and structures, reduce technical debt, remove waste and optimize

Das ganze ist natürlich ein iterativer Prozess. In der Analyse-Phase werden alle Stakeholder befragt, es können Qualitätsanalysen und statische Code Analyse zum Einsatz kommen. Erst im zweiten Schritt werden die ermittelten Probleme bewertet. Ziel dabei ist, die Stakeholder zu überzeugen, die Probleme anzugehen. Im dritten Schritt wird dann eine Auswahl an Verbesserungen angegangen. Dazu steht ein Fundus an Mustern bereit.

aim42 soll nur „Industrie erprobte“ Muster und Praktiken enthalten. Es gibt auch ein github-Repository.

Es hat mich beeindruckt, dass die beiden auf der OOP2014 diesen Ansatz gestartet haben.

Die Präsentation-Folien sind online verfügbar.

This entry is part 1 of 7 in the series OOP 2014 Report

Dieses Jahr bin ich drei Tage auf der OOP Konferenz. Hier einige Notizen zu den von mir besuchten Talks und Keynotes. (noch nicht ganz fertig)

Enterprise Application Integration War Stories

So viele Stories waren es dann doch nicht. Die beiden Vortragenden sind u.a. auf die EAI-Patterns eingegangen. Erwähnt, weil mit Erfahrung hinterlegt, wurden Apache Camel und Spring Integration.

Zitate:

Gerade bei Parallelverarbeitung ist das Testen der Fehlerfälle notwendig!

Further tips: small building blocks. No shared mutable state

Keynote „Parallel Programming Design Patterns“ von Tim Mattson (Intel)

Früher: CPU-Performance am wichtigsten, heute: Stromverbrauch. Daher wird zukünftig die Zahl der Cores zunehmen, nicht die Performances des einzelnen Cores.

Damit muss sich die Software ändern, denn die Hardware wird nicht einfach immer „schneller“ (wie früher).

Parallelisierte Software muss her. Hierzu gibt es Design Patterns in mehreren Kategorien. Die kann man anscheinend wunderbar kombinieren.

Beobachtung aus der Game-Industrie: kleine Zahl von „Effizienz“-Entwicklern (Hardware nah), große Zahl von „Anwendungsentwicklern“. Beispiel der Umsetzung: Spezielle JIT-Optimierer, die die Verwendung eines bestimmten Frameworks erkennen und den Code optimieren.

Reactive Programming

Überblick. Beispiele für Sprachen: Erlang und Elm. Hinweis auf das Reactive Manifesto. Frameworks wie Rx, Akka etc. als „Mittelweg“

Keynote: Adaptive Actions

Adaptive Action is a reflective process that guides you to take action in times of uncertainty. Siehe adaptiveaction.org

Integrationschaos

Im Integrationstest kracht es häufig – „what to do about it?“

  • Functionale und technische Specifikation erstellen, Communication contract
  • Formales Review
  • Simulatoren für die Entwicklung, ggf. auch Test
  • Test Data Management

zu letzterem Punkt hat er leider wenig gesagt, wäre interessant für mich. Ein Ansatz wäre, in der Datenbank ein „Soll“-Schema zu haben und dieses zu Beginn der Test in das eigentliche Schema zu kopieren.

Unvorhersehbares handhaben

Eine Folge von 7 Pecha Kucha Vorträgen von Bernd Österreich und sechs seiner oose-Kollegen. Manchmal fand ich den Zusammenhang zu „Unvorhersehbarem“ etwas bemüht, etwa beim Teil zu „agilem BPM“ und „Adaptive Case Management“.

Interessant fand ich, dass es für die OMG ein Austauschformat für „Case Management“ (Fallbearbeitungssysteme) definiert hat.