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.

Preparation

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.

D-Day(s)

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.

Post-processing

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.

Developer turned Product Owner

The backlog is a mess. The order is random. There’s no grouping or coherence, let alone a vision of any kind. Stories are unclear, if at all described, and sprint planning takes forever while developers try to figure out what the product owner wants. I heard these complaints over and over again from teams, and then I had a chance to become a product owner myself. Turns out it’s not much different from a developer’s work.

TDD

Taking an agile approach means making small steps and testing how they influence the product. Just like TDD in programming:

  1. Think what you want to do.
  2. Decide how you will measure success, like you code a test.
  3. Have the team implement your idea, usually by writing code and just enough to make the test pass.
  4. Evaluate the idea against your KPIs, like you would run your test.
  5. With the findings, go back to 1 to adjust your hypothesis and approach.

Clean Code

The backlog items you’re preparing—usually stories, will be read and relied on by the team to build a product increment. The clearer the language, the easier it’ll be to understand and follow.

  • clear, unambiguous, expressive naming,
  • precise vocabulary,
  • short paragraphs,
  • good English (or any other language you use),

all of these are qualities that’ll help the team deliver faster and with fewer misinterpretations. All the same in code, where good naming for variables, functions, objects matters, and short, focused functions and components are preferred.

Abstraction

A good backlog is well organized, with related items grouped together into epics, aligned along a vision for the product. This in turn provides direction and focus for both the team and stakeholders, guiding conversations on how the product should be shaped, deciding what fits in and more importantly what doesn’t. It allows setting release and sprint goals, that the team can measure their progress against.

All this is exactly like abstraction in code, where similar logic gets grouped into objects, similar objects grouped into packages, named after the domain they cover. From an orderly, well-named code base one should easily be able to identify the purpose of the system, decide where to put new code and whether it belongs in there at all.

I know what the team’s doing

My programming experience is helping me tremendously in shaping the backlog and working with the team. Requirements are crisp, or quickly refactored to become so, order is clear and it’s easy to see what fits into our current vision and what should be deferred.

On top of that, I know the work the team does. When they come back reporting issues with implementing certain items, I understand those and we can easily adjust plans to reality, with the new information we received. Everyone’s work becomes easier and we’re steadily moving forward.

Obviously not every developer would make a good product owner. There’s a lot of touchy-feely people work involved, while many will likely prefer to deal with the clear, binary logic of computers. But for those who always liked to work on the edge between technology and people, this might just be the right career advance. One that’s surprisingly easy to make.

Seventy percent of the time Swiss

Boarding an airplane on Monday morning, coffee in hand, yawning, flying to Zürich for a week of alternating between the customer’s office and hotel, then back in the air on Friday evening to reach base—my home in Warsaw for the weekend. That was the offer I was given a while ago, good money, challenging work. I replied “no, thank you“.

Mind you, I am by no means bound to where I’m living currently, even though I love it here. There are many other extraordinary spots around the world where I could see myself moving. It’s just this particular arrangement that wouldn’t suit me—torn Schrödinger-style between two locations, neither really here nor there.

It would’ve uprooted me from all the current affiliations I had here, in Warsaw—the TEDx people, startup communities, Toastmasters and personal relationships. On the other hand, my temporary Zürich tenure (or anywhere else for that matter) wouldn’t have let me get engaged in anything meaningful there, since these relationships take time to develop and produce results.

There would be also practical consequences to consider. Since I would’ve been spending only weekends here in Warsaw, I’d want to maximize my enjoyment of them, so I’d have to pay somebody to clean my apartment, do laundry and arrange for all the other chores to be done, so that I can rest, catch up with family and friends. And I likely would’ve been spending vacation at home, sick of all the traveling.

There are times in life when that sort of work mode could be acceptable, perhaps even exciting. Usually that’s when one is younger, has no spouse, little experience. With time one learns that things of value require time and commitment to build, often related to one’s personal presence somewhere for an extended period of time. We might be living in a digital age, but we’re still very much physical creatures.

Antique inspirations for software architects

The Roman architect Vitruvius around the year 15 BC completed his impressive, ten-volume treatise on architecture—De Architectura. It covers every possible type of man-made structure ever needed by the people of his time, but starts out wisely by prescribing basic qualities that good architecture must embody:

All… must be built with due reference to durability, [utility], and beauty. Durability will be assured when foundations are carried down to the solid ground and materials wisely and liberally selected; [utility], when the arrangement of the apartments is faultless and presents no hindrance to use, and when each class of building is assigned to its suitable and appropriate exposure; and beauty, when the appearance of the work is pleasing and in good taste, and when its members are in due proportion according to correct principles of symmetry. [emphasis mine, and I prefer ‘utility’ over ‘convenience’ in the original quote]

Vitruvius, De Architectura, Wikiquote

Sounds familiar? It certainly did for me when I was brainstorming the set of values that our newly minted team of software architects was to adopt. Durability, Utility and Beauty described perfectly how I thought about good software architecture.

  • Durability means that software must stand the test of time. Work as long as necessary without crashing or requiring mid-way reboots. And it shouldn’t need to be rewritten from scratch every few years, but instead adapt well to changing needs. This principle guides the selection of languages, platforms, frameworks and tools.
  • Utility means the software must fulfill requirements that it was given and must do so well. If it’s a user-facing application, it must be easy to use and supportive, if it’s meant to handle high load, it needs to scale well. If it exposes an API for others to connect to, that has to be comprehensive and flexible. We need to build software always with its intended purpose in mind.
  • Beauty means the software must be pleasing to the eye. A clean, simple UI, laid-out and colored for readability. Inside, a logical layout of components, packages and modules. Good, clear but concise naming, plenty of whitespace, short functions, variables of unambiguous purpose. Computers will read anything. We need to code for people. This principle underlies front-end and coding style guides.

We unanimously decided to adopt these two-millennia-old qualities as our team’s values and to visualize them, I proposed an image that would become our logo: the Millau Viaduct—a spectacular bridge designed by sir Norman Foster, built near the city of Millau in southern France.

Millau Viaduct

Bridges ideally embody durability, some serving the public for centuries, like the Charles Bridge in Prague, opened in 1402. Getting people efficiently and safely across rivers, valleys and canyons is as clear an illustration of utility as we could hope for. And while beauty is in the eye of the beholder, to us Millau Viaduct truly is beautiful, with its slender structure suspended over the Tarn valley like a delicate web of strings.

We’re using these values to ask better questions. Is it durable? Will this fancy framework you have spotted at some conference be around in two years? Are you sure we need the user to click three times to submit the order? Can we make it easier? Can you read your own code? Can your new team colleague read and understand it? Old lessons that continue to hold true in an age technically so much more sophisticated than when they were put in writing.

Photo of Millau Viaduct by Phillip Capper.

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.