The unexciting GOTO Berlin 2017

Unexciting. That’s the one word I would use to describe this year’s edition of GOTO Berlin. And I’m suspecting it’s a sign of advancing maturity. Just not sure whether it’s the industry’s, or my own.

This year was my second time at GOTO Berlin, after I attended in December 2015. I came back because the first time I was really satisfied with the content. Lots of fresh, practical, accessible ideas, well-presented (unlike, say, QCon London 2016). Plus, the keynotes were tremendous fun.

GOTO Berlin 2017 Convention Hall

Keynotes are always tricky for the organizers, because you want them to be somewhat abstracted from the low-level themes of sessions, but not too far away, so that the audience can still relate. Plus, they need really engaging speakers. GOTO Berlin pulled this off perfectly. The 2015 edition had space-themed keynotes about the Apollo and Space Shuttle programs, mighty interesting. This year featured a variety: Mars exploration, data science, autonomous systems and data security. Really, really good content.

This year’s sessions, however, surprised me with how little new stuff there was. Nothing really bleeding-edge. Same topics I keep hearing about for the last two-three years: microservices, DDD, containers (and agile, of course, but I staid away from “soft” themes). Even serverless, that I thought would be the buzzword of this year, seems ubiquitous and long-tamed.

Not that any of these are boring—to the contrary, they’ve now reached mainstream adoption and presenters have a lot of real-world experience to share (as opposed to theories and hopeful evangelization). It’s just… what happened to the breakneck speed of “innovation” in this industry?

Granted, there was a lot of talk about AI, which seems to be the bleeding-edge stuff these days. But I staid away from those sessions too. We still need to prove we can deliver well-structured “dumb” software before we can think of constructing anything “smart”.

So, what did I see?

Rust and WebAssembly were the only real, new things for me. Emerging languages and platforms, the first one may help us make proper use of concurrency and multi-core processors:

and the latest Firefox release already benefits from it. The second might help us build advanced applications for the web.

The rest of the sessions I attended were all about: how do you deal with the real world? Not some fresh, hot framework or cloud service, but the day-to-day grind of working in a business environment, modeling a highly irregular world in code, maintaining multi-year- and decade-old legacy code. All of this in a time of cheap networking, favoring distributed systems, where failure is the rule, not the exception.

It may be that the industry has changed. Reflected on itself and found that technological novelties are fun, but often leave real-world problems unsolved. Came back to Earth and asked itself “what are we really trying to achieve?” Or… it may be that I’m the one who changed. I still enjoy new toys, but there’s work to do down here. An approach that informed my choice of sessions to attend, and so influenced my impressions.

Michał’s conference war chest

It’s not unusual for conferences to cost an arm and a leg. At €1,000 or more for just the entry, on top of which come travel and accommodation, and I often attend two or three events a year. That’s a pile of money in need of justification spending, and I can only do so if I bring back lots of valuable information. Here’s what I do nowadays—the tools and tricks I worked out for surviving and thriving as a conference attendee.


During a conference I want to focus strictly on acquiring information and connecting with other attendees, so to free up time I prepare a lot upfront.

Session selection comes first. Conference schedules usually appear piece by piece, so a week or two before the event I go through all sessions and plan my agenda. The last thing I want is to make haphazard, effectively random decisions at the venue.

  • If I’m attending with any colleagues, we sit down together to split up the sessions and cover more ground.
  • If there’s more than one interesting session in a given time slot, I write down all of them and prioritize. This way I have more options when my first choice turns out to be a flop or suddenly gets canceled.

I add selected sessions into Google Calendar, synchronized across all of my devices. Some conferences have dedicated apps to store one’s schedule, but these may or may not work to my liking or could have issues on shaky Wi-Fi. Plus I quickly would’ve acquired a pile of useless apps and accounts.

GOTO Berlin schedule in Calendar

I’m really big on notes. Before the conference I setup a fresh Google Doc, since I’ll be taking notes on a tablet, with pre-entered:

  • sections for each chosen session, ordered chronologically,
  • names and
  • Twitter handles of speakers.

GOTO Berlin conference notes

Using Google Docs has a number of advantages:

  • I can share the document with colleagues, both at the venue or back at the office, where they can follow me in real-time,
  • Google Docs’ context-aware spellchecker is pretty decent, which helps a lot when (mis)typing on a tablet,
  • the chronological order lets me get ready quickly by opening the document and scrolling down to the next empty section,
  • speakers’ Twitter handles make live tweeting easier.

I’ll often write the Twitter handles with the conference hashtags, ie.:

 @mpaluchowski #craftconf

Note the leading space. This snippet I can easily copy and paste after every quote I tweet during a session.


The conference days are always intense, both physically as well as mentally, so my focus here is to stay light and fit.

I carry my own shoulder bag, currently the excellent Camel Active Dakar, which contains my tablet, wallet, business cards and a pen or two.

Camel Active Dakar shoulder bag

Conferences usually hand out their own bags, but most of these aren’t convenient to carry around for a full day. I carefully selected a good bag, that:

  • keeps my hands free all day—especially beneficial at standing lunches,
  • doesn’t bite into my shoulder(s),
  • doesn’t bump around my hip thanks to its vertical orientation,
  • easily fits into my lap during a session, when space is tight,
  • carries everything I need—the Camel one can easily carry a 12″ laptop or A4-sized documents.

Michal taking notes at CraftConf 2015

My device for note taking is currently the iPad Air 2. A laptop wouldn’t do because the vast majority won’t last a full day on batteries and I sure as hell don’t want to waste time on recharging.

Typing on a tablet is pretty cumbersome, but gets better with practice, plus Google Docs’ spellchecker helps a lot, and anyway I won’t be publishing raw notes anywhere without post-processing. A colleague is happy doing notes on an iPad Mini so the smaller form factor could work as well.

iOS 9’s Peek function was a real blessing, since I tweet a lot during sessions, on top of taking notes. Earlier I had to keep switching between the Google Docs and Twitter apps, whereas now I can just slide in Twitter on the side for a quick tweet and return to notes. Thanks, Apple!

A conference day is really hard for the body since I spend a lot of time sitting still in sessions, while my brain keeps working in high gear, burning lots of fuel and not getting nearly enough oxygen to clean up the trash from metabolism. This means unless I pay attention to my body, by the end of day I’ll likely develop a headache and won’t see much from the conference party. So I:

  • drink a lot of water, either carry my own bottle and keep sipping during sessions, or drink a glass at each break. The side effect is having to visit the bathroom often, but there’s a trick to that too.
  • move a lot in between sessions—no sitting, lots of walking, gesticulation, even leaving the venue when possible.
  • eat light, opting for complex fuel sources, like protein or complex carbohydrates. No pastry or sweets of any kind—these would burn up quickly leaving me hungry and distracted.

Finally, I try to sit near convenient exit rows, so that I can easily leave the session if I don’t like it, or reach the toilet before the crowd does. Trust me, this is a real problem during male-dominated software events.


There’s little value in all the information I acquire at a conference if it stays inside my head. Sharing it with others and turning it into action is where the payoff starts.

Conferences are often followed by a weekend, which is super convenient since I can focus on something completely different and then go back to my notes with a fresh look on Monday morning.

It takes me a day or so to process notes, where I rearrange them to:

  • group into common themes, ie. microservices, DDD, Agile etc.,
  • reorder into something that makes sense in the context, rather than whatever the speaker(s) thought would,
  • list out tools, books, blog posts and other resources I saw mentioned,
  • later add links to talk recordings, once they were posted.

Finally, I produce a brief summary from the pile of information, adding my own judgment of where I see the industry right now, or how it changed compared with previous conferences. This usually turns into a blog post, richly decorated with photos and tweets from the event.

We take a look at all materials with my colleagues to decide what is most relevant to us and what we’d like to try out now or later. These go into our regular planning and I get back to everyday work, counting down to the next great conference.

The state of the craft at CraftConf 2015

CraftConf in sunny Budapest aims to be the conference in Central Europe where developers share what’s state of the art in building software. Joining the 2015 edition was an easy choice, after the first edition a year earlier received rave reviews from attendees. Three days, 16 talks and a workshop later I emerged with 6,062 words worth of notes, distilled into a few broad trends that seem to represent the edge of the industry right now.

CraftConf 2015 Stage

Microservices entering the mainstream

At SoCraTest 2014, less than a year ago, a lot of people were still asking basic questions about microservices—what they are, how to build them, how are they different from any other SOA approach. Not anymore. CractConf saw a lot of companies sharing battlefield experiences with these architectures—what works, what doesn’t, whether to consider the approach at all and how much it will cost.

  • Microservices are a means to scale the organization—allow many people to work on the same system, reduce dependencies, and thus enable rapid development without having to coordinate huge releases or continuously breaking one another’s code. They’re routinely described as “easier to reason about” and built to “minimize the amount of program one needs to think about” by the very virtue of being small and focused on doing one task well.
  • Microservice ecosystems at established companies routinely consist of 50+ and even 100+ services, usually built in a whole range of technologies. If a single service is small enough, say “2,000 lines of code“, or “takes 6 weeks to build from scratch by a newcomer” (both actual definitions), then building one in a wholly new technology is easily sold as an inexpensive POC.
  • All companies successfully implementing microservices started out with monolith applications and afterwards split out the services one at a time. This approach was broadly recommended, even for greenfield projects, because monoliths are easier to refactor while the organization works to research and understand its product better.
  • The supporting tooling is already there and mostly quite mature. Early adopters, like Netflix, had to build their own tools, which they later shared and improved with the open source community. Meanwhile, commercial tools popped up, offered by specialized vendors, with support contracts and other conveniences that pointy-haired bosses like so much.

But most importantly:

To benefit from microservices without getting killed, you need to:

  • automate everything—builds, testing, deployment, provisioning of virtual machines and container instances. It’s the only way to manage hundreds of running service instances.
  • monitor everything—each service must have its own health checks, showing whatever information is most relevant. Typically numbers of transactions, timings, latency, hardware utilization, but often also business KPIs. You’ll also need a means to track requests flowing through the system, ie. by IDs being passed in service calls. This information must be available to development teams in real time.
  • build for failure—crashes, disconnections, load spikes, bugs, all of which will occur more often than with monoliths. Make sure failures are reported, tracked, and the system is self-healing, via techniques like circuit-breakers, bulkheads or resource pools. Work with business representatives to determine for each use case whether consistency or availability are more important, because you cannot always offer both.

Not everyone was pleased with such a high degree of saturation with microservice themes at CraftConf:

But that only proves that this architecture is well past the stage of early adoption and entering into the mainstream.

Everybody has an API

The consequence of adopting microservices is that APIs become the norm, starting out internally, and often “sooner than you think” being made available to the outside world, either to support different devices or integrate with 3rd parties. Their costs also became more evident:

  • An API is for life. Once it becomes public, it’s very difficult to change, so early design mistakes become much more difficult to fix.
    • Use techniques that allow you to add new fields and methods to an API without disturbing clients.
    • Semantic versioninig, coupled with decent deprecation procedures, help move the process of making backwards incompatible changes.
    • You’ll still have customers who “missed the memo“, whom you may have to offer commercial legacy support for an additional fee.
  • Create good documentation, generated and published automatically.
  • Assign people who will be monitoring community sites, like StackOverflow, for questions regarding your API.

@ade_oshineye (of Apprenticeship Patterns fame) was spot-on summarizing the process of deciding whether to create an API by showing an analogy to puppies—everybody wants one, but not everyone is ready.

Moving towards Domain-Driven Design

Frameworks these days tend to dictate the design of applications by suggesting organizing code by layers into packages like models, controllers or views. The consequence is that:

  • modifications to a single business scenario require often changing code in many packages,
  • it’s all too easy for components to reach into layers outside their hierarchy, too deep down for their own good, while they should only be calling public APIs,
  • there’s very little information presented by the package structure on what the application does.

Several speakers postulated that this should stop and instead code should be packaged by business units, with relevant models and controllers sharing the same packages. Encapsulation could further be improved by changing method and component access to package instead of the common public. It’s an old theme that finally seems to be getting traction, with past support from developer celebrities like Uncle Bob:

What do you see? If I were to show you this and I did not tell you that it was a Rails app, would you be able to recognize that it is, in fact, a Rails app? Yeah, looks like a Rails app.

Why should the top-level directory structure communicate that information to you? What does this application do? There’s no clue here!

Robert Martin, Architecture, the Lost Years

Well worth watching.

TDD and Agile now taken for granted

Two themes notably absent from the vast majority of CraftConf talks were TDD and Agile. They implicitly became accepted as defaults—the baseline, cost of entry and survival in the game of software development.

  • Microservices will only reach their full potential when their owning teams can work and make decisions independently from central authority, including frequent deployments to production.
  • Frequent, decentralized deployments require comprehensive, automated test coverage.
  • TDD drives the design of code, meaning every line exists only to make a failing test pass. “Every new line of immediately becomes legacy code” so code as little as possible.
  • Google continues to build new tools to satisfy business problems they are facing—tools that often get adopted company-wide, but never enforced. They call it an evolutionary approach, where the best ideas will be adopted simply on merit, while the others will die in obscurity.
  • @cagan argued how the whole top-down oriented product design cycle is broken by being grossly inaccurate and too heavy, and companies need to adopt bottom-up idea spawning and rapid testing instead.
  • Transparency is key, so that everybody can make better decisions based on as much information as possible.

Oh, and “doocracy” is a word now:

A vibrant community

It’s been a blast to mingle with some of the 1,300 energetic attendees, meeting friends, old and new. @MrowcaKasia and @kubawalinski turned from Twitter handles into real, live, and engaging persons. The slightly grumpy but ever competent @maniserowicz is always a pleasure to meet, and then there’s the whole SoCraTes gang of @leiderleider, @c089, @Singsalad, @egga_de and @rubstrauber, whose passion for community and craftsmanship continues to inspire.

The 2015 CraftConf was only the second edition, but already organized with such painstaking detail, that I can easily call it the best conference I’ve ever been to. The team’s already fishing out and working to improve what didn’t quite work this year, so next year’s event is bound to be even more polished.

The unconference experience of SoCraTes 2014

Flip-flops, sandals, occasionally a pair of Vibram Five Fingers and some people walking barefoot. It’s the definition of the laid-back spirit at SoCraTes 2014, an unconference I joined last week, made for and by software craftsmen. It was my first ever unconference experience and while I found the format unsuited for my personality, the energizing power of that community was exceptional.

SoCraTes logo

SoCraTes stands for Software Craftsmanship and Testing – an all-in-one statement embodying the aspiration to become better at creating software tomorrow than we were today. That’s all there was available before the event to describe its contents. No calls for papers, no formal agendas, speaker profiles or anything one would expect from a regular conference. All sessions for the day were announced each morning, often sparked by the previous night’s conversations. One literally comes there without knowing what to expect.

Pitching sessions

For two days, first thing after breakfast, all 150 of us met to fill in the agenda, by pitching sessions and sticking them somewhere onto the grid of available times and spaces – a morning conference-room lecture on micro-services, or perhaps an afternoon debate on freelancing strategies in a garden setting? Anything was possible, because in Open Space Technology:

  • Whoever comes is the right people.
  • Whenever it starts is the right time.
  • Wherever it is, is the right place.
  • Whatever happens is the only thing that could have.
  • When it’s over, it’s over.

and perhaps most importantly:

Law of two feet
If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else.

SoCraTes attendees spent days strolling between sessions, then evenings and nights playing board games, learning to juggle, explaining complex software architectures with beer glasses, or mob-programming in Cobol.

So, how was it for me? Mixed.

There are consequences to participating in an unconference. On the positive side, there’s the flourishing creativity. Every single person I met at SoCraTes was passionate about their work to the point of making me ashamed that I didn’t know enough about the field and probably didn’t work hard enough to learn. I actually had to get some work done in-between, just to improve my morale, like finishing a blog post and publishing a microscopic framework for content websites.

On the negative side, however, was a certain level of disorganization and common lack of substance. With no information on sessions published beforehand, there was no way to make a reasonably informed decision about which ones to attend. I had to decide on the spot, at 9 o’clock in the morning of the day, based on titles and 30-second pitches. A few people came with prepared sessions, but many just improvised them.

The result is that most sessions ended up being discussions. A session owner may have introduced the topic and then some of the people present talked through its selected areas. While that’s a useful form for a meeting of peers trying to fill in their gaps in knowledge, it doesn’t work well for the less experienced who would like to learn in a more structured fashion.

In theory, the law of two feet removes the burden of having to sit through a bad session, but in practice leaving one session makes you arrive at another one mid-way, which often makes it difficult to join in and follow the flow of information.

After the two days I didn’t feel I took away much, despite the amazing variety of sessions and the astonishing scope of knowledge of all their attendees.

In Philip Zimbardo’s classification of time perspectives, I’m clearly a future-positive-oriented type. I like to prepare ahead and anticipate what’s coming. I also like concise conference sessions where presenters share the experience of their past work, like describing a specific project, a piece of software they built, and the lessons they took away from it. Concrete, credible, and structured.

Unconferences are great because of the people who attend them. Competent and passionate to the boundaries of craze. That’s what keeps those who enjoyed SoCraTes coming back. They seek renewed inspiration and energy coming from others like them. It’s perhaps the most social gathering of geeks.

For the future I will likely stick to more traditional conference formats, with curated agendas. SoCraTes 2014 was a very well organized event and for anyone who feels comfortable with the format, the upcoming editions will be thoroughly enjoyable.