Trifork Blog

My Goto Amsterdam 2014

July 17th, 2014 by

Trifork Logo

People who have worked with me know I’m a bit of a technical conservative. I’m very wary of quickly adopting the latest fads and trends because I’ve seen the collective hype and the following disillusionment too many times, including software being built with the then-latest-hype framework or platform and a year later being stuck with now-obsolete technology that only the original developers and a handful of other people still have any real experience with.

For the same reason I’ve avoided software tech conferences in the past years. A few visits to conferences several years ago on each occasion left me with feeling that I’d heard a lot about a lot, but that it wasn’t really going to improve my daily software development work.

Luckily, Goto Amsterdam 2014 was different.

Many, if not all, of the talks were relevant to my actual, day to day, software development job. I learned about looking at Agile in a different way. I heard people speak on real life problems being solved with actual, current, widely adopted technology. I even listened to talks that weren’t really that much about software development at all.

So let me walk you through my Goto Friday.

Rod Johnson – Things I wish I’d known
(Opening Keynote)

The co-founder of SpringSource started the day with his keynote about what it’s like to be an entrepreneur starting up a technology company. I’d never heard Rod speak before, I found out that he is an entertaining speaker.

Besides the obvious points — not all startups are successful; you will sacrifice your personal life; be careful from who you get your funding and under what conditions; don’t just do it for the money — there was some food for thought not only for those looking to start a company but also for all of us in the personal enterprises of our jobs and lives. The following points stuck out for me:

  • Before you start: be sceptical about what you’re doing. Is there actually a need for what you’re creating? Why will you succeed? Talk to people about your ideas, be open to criticism.
  • Once you’ve decided on what you’ll do: believe in it. Be certain in a non-rational way. Don’t let people throw you off.
  • Find the balance between being confident about what you’re good at and knowing when to ask for help (knowing what you suck at)
  • People are more important than technology


After leaving the more than adequately airconditioned auditorium and warming up over a cup of coffee break in the hall, it was time for the next session:

Simon Brown – Software architecture vs. code
(Software Architecture track)

In a nutshell, this talk was about how to draw good software architecture diagrams.

The two key points Simon addressed in his talk were:

  • Chosing the right abstractions and communicating them effectively
  • Ensuring that your architecture diagrams have a correspondence to your code

Chosing the right abstractions and communicating them effectively

People have different ways of drawing diagrams. A count of hands in the audience showed that barely anyone uses UML, or uses it in the official, “correct” way. In the end, the abstractions we chose are much more important than having a common notation.

Simon introduced the “C4” model of four levels of abstraction:

  1. system context
  2. containers
  3. components
  4. classes

By starting at the “system context” level, which shows which external systems the system we’re building interacts with, and drilling down, we get several diagrams that allow us to communicate effectively about our code by visualizing it at the relevant level of abstraction.

This led to the second point of how to make sure the diagram has an actual correspondence to our code, not just in a conceptual way, but physically.

Ensuring your architecture diagrams have a correspondence to your code

We’ve all been taught about the benefits of n-tier development, but in practice having these tiers slice through all of the components in our system leads to code that’s structured like this (i.e. in packages or namespaces):

  • model
    • componentA
    • componentB
  • controller
    • componentA
    • componentB
  • view
    • componentA
    • componentB

So in our component diagram, we show these components as self-contained elements, but in reality they’re distributed across the tiers of our system. Simon proposed using functional structuring of our code first, then structuring by tiers:

  • componentA
    • model
    • controller
    • view
  • componentB
    • model
    • controller
    • view

In this way, components in our architecture diagram correspond to packages in our code.

Another point was using the same language in code that you use in the architecture diagrams — ideally vocabulary familiar to the people working in domain.

Unit testing

The components in the architecture are essentially black boxes with a clearly defined interface and internals that we don’t care about as long as they correctly implement the interface. Hence, unit testing here means testing components, not classes.

Further reading: “Just enough software architecture” – George H. Fairbanks

The Trifork stand in the hall could be located just by following your nose: they were baking fresh stroopwafels, a Dutch pastry that you have to try if you’re ever in the country. But even for a born and bred Dutchie like me, freshly baked stroopwafels are a special treat: they taste so much better than the ones you get at the grocery store!

So with a full stomach, on I went to…

Linda Rising – Beyond agility – resilience
(The Future of Agile track)

To come to a software development conference and have a woman, and a 72-year old one at that, get up on stage to deliver a talk was a true delight. Any type of evidence that the software development trade is moving out of the hands of young white males to a more diverse demographic makes me smile inside. And Linda’s talk was a true pleasure to listen to.

How do we view success? When someone succeeds at something, is it because they’re talented, or is it because they’ve worked hard at it? Very simply put, this is the difference between the “fixed mindset” and the “growth mindset”, Linda described. A quick table  of key points:

Fixed mindset vs growth
ability: static can grow
goal: look good learn
challenges: avoid embrace
failure: defines your identity provides information
effort: for those with no talent path to mastery
reaction to challenge: helplessness resilience

“What we say to each other impacts our mindset”

So why do some people have the fixed mindset and some people have a growth mindset? Scientific experiments one animals and humans show that if we feel we don’t have control over our environment, we tend towards a fixed mindset (read about Martin Seligman’s research on Learned Helplnessness). But there’s more to it.

Consider a child that scored well on an exam. One parent may say to such a child: “Well done, you’re really smart!”. Another may say: “Well done, you worked hard!”. Things like this shape a child’s mindset. The former, when failing an exam, will despair: apparently they’re not that smart after all, and that’s the end of it. The latter will realize that with more hard work, next time, they may do better.

“Resilience is the capacity to adapt successfully in the presence of risk and adversity”

So how do we deal with failure in our software development work? Linda mentioned the ABCD model developed by Albert Ellis, PhD. It describes how an Activating event (A) combines with our Belief system (B) to create Consequences in our emotions or behavior (C). If failure causes us to feel helpless, we need to change our belief system; that’s the D in the model: dispute, i.e. teaching yourself to look differently at how you interpret events.

One of the keys to acquiring resilience is minimizing catastrophic thinking. Instead of imagining the best case or worst case outcome of a situation, we should look at the most likely outcome.

Applied to Agile software development, this means not being afraid to take risks. Failure doesn’t mean we did something wrong, it means we did something right: we learned something. Interesting enough, this is more or less what Dan North said in his talk later on in the day


Time for lunch. And the sponsor raffle. Without the sponsors this whole event wouldn’t have happened, so I salute them anyway.

Phil Wills – How Elasticsearch powers the Guardian’s newsroom
NoSQL Track

This talk spiked my interest as I’m currently with a client in the same field: news publishing.

Phil and his team replaced their standard Google Analytic-based dashboard with a custom-made one. Their solution improved analytics in the following ways:

  • analysis is now realtime instead of per hour: the editors want to be able to tell quickly whether, for example, adding keywords to an article improves traffic to that article
  • analytics are combined with the content of articles, etc. to provide a comprehensive view
  • terminology is tailored to language that is familiar to people working at The Guardian, making it user friendly

They use ElasticSearch, and especially its relatively new new data analysis and statistics features. They start a new index each day which keeps it scalable. They make heavy use of aggregations, the successors of facets in ElasticSearch. The front end uses D3 and Rickshaw for graphs.

Interesting to see how a real life problem is addressed with relative ease in ElasticSearch, and to see how despite its tagline “You know, for Search”, ElasticSearch is becoming more and more about data analysis instead of just full text search.

Dan North – Accelerated agile: from months to minutes talk
The future of Agile Track

Dan North provided some fresh insights on Agile development based on their experiences developing a stock trading application:

1) Have good domain knowledge

Always have at least a domain expert in the team. Study the domain. This way you can communicate better with the client and think with them about problems and solutions.

2) Prioritize risky over valuable

Scrum emphasizes implementing things that provide the most business value first. But what is value? The stuff that’s going to teach you things. So you want to learn these things as early on in the project as possible. This will reduce uncertainty about the domain and about technical choices to make.

Pulling these risky things to the front of the project means you might have some failures early on in the project. But if we think about failure as an opportunity to learn and get information, that means it’s not a bad thing. (Remember Linda Rising’s talk earlier on?)

3) Plan as far as you need

4) Try something different

Try a new programming language, a new programming style.You may find out it’s not as good as what you were doing, but then you’ve at least learned that. More likely you will at least be inspired to make some improvements in the way you work and write code.

5) Fire, aim, ready

Get something (anything!) in front of users as quickly as possible: this provides valuable feedback. Show them something new every day, even if it’s not completely finished and bug-free.

6) Build small, separate (replacable) pieces

DRY is the enemy of decoupled. Sometimes copying some pieces of code is warranted when it provides greater decoupling. Less inter-component dependencies means less chances for bugs.

7) Deploy small, separate pieces

-> Make component deployment quick

-> make full app deployment consistent

-> make components self-describing (heartbeat)

-> make environments unsurprising (every VM identical)

8) Prefer simple over easy

Simple means requiring a lower cognitive load, i.e. easier to understand.

9) Make the trade-offs

  • Buy vs. build vs. open source
  • Learning a library vs rolling your own: Is it really worth learning a new library and finding out about its quirks when you just need a small bit of functionality that you can roll in a shorter time?

10) Share the love

Do pair programming and code reviews

Try “learning lunches”

On-boarding: get your end-users close, even at the same desk!

11) Be OK with failure

We’re in the business of product development, not project delivery. The sooner we fail, the sooner we make progress in the product we’re building.

Jessica Kerr – Functional principles for object-oriented developmers
Fashions vs. Fundamentals

In a small room with tropical temperatures on the second floor of the Beurs van Berlage building, Jessica conveyed to us with quite some humor some lessons she learned from functional programming languages that we can apply to Java programming to make our code better. She mentioned a few times the virtues of the Optional and Tuple types in her talk. Every now and then she brought the “fuzzy grey koala of compromise” to the scene to show what to do when functional programming principles just can’t be applied to real world Java code.

We make our code less complex and easier to understand by choosing what not to think about. If we don’t have to “run the code in our head” to understand what it does, it reduces the potential for error.

Data in, data out functions

Functions without side effects make for easier-to-read code. If we can’t void side effects, at least make the function idempotent.


A “firstName” property might be a String, but if we define a new type FirstName for it, we can be sure we never mix it up with any other kind of String. Advantages are:

  • It makes the code more expressive
  • Types provide a skeleton of program structure
  • It enables reasoning about code based on types without having to “run the code in your head”


Immutability means less complexity (data is initialized in the constructor and only there), no issues with concurrency

Return Optional<> instead of null

No more NPEs!

Declare what, not how: Streams API in Java 8

This is for me the one reason to start using Java 8 today. The streams API allows you to much better express intent (what) instead of implementation (how).

Linda rising – Science or stories?
Closing keynote

Why do we use Agile? Have we read any scientific papers describing double-blind studies showing how Agile is in some way better than another way of working?

A room full of IT people, most of them with a degree, had to answer no to this question. So why do we use it?

Linda led us through medical history showing that the decisions we make are all but rational. If we do rationalize, it’s usually after the fact. However, if something sounds logical, and we hear stories from people testifying to how well it works, we believe it.

So we should do both: test ideas AND share stories.

Further reading: “A final word about stories” – IEEE Software March/April 2014

What a day! My head was full with information, much of which still needs to find a place and an application. But Goto Amsterdam 2014 inspired, challenged, and motivated me.

Till next year!

Comments are closed.