Impressions from SoCraTes 2017

conference / agile / software craft / games / testing

I attended SoCraTes 2017 in Soltau. SoCraTes is an “Unconference”, where the participants set their own agenda and come up with topics for their sessions. Sessions can be presentations, workshops and open discussions.

Here are the notes from some of the sessions I attended:

Programming Exercise: Banishing State

The example of this exercise was taken from a real-life project: A book indexing service that takes keyword/page number pairs as input and outputs either the page number, a range of page numbers or nothing, depending on previous inputs. The title might be a bit misleading - you have to store state somehow, but this exercise is about managing state in a sane way.

In my opinion, this session was not suitable for a 50-minute time slot at the start of a conference: Explaining the problem took 15-20 minutes and setting up an environment with non-working WiFi was a challenge. Nevertheless, I enjoyed working on the problem and got an impression of how easy programming, testing and refactoring is with Typescript.

Kata source and explanation: https://github.com/marcoemrich/index_kata

Softwarecraft Fiasco Development

Fiasco is an award-winning storytelling game. Quote from the web site:

Fiasco is inspired by cinematic tales of small time capers gone disastrously wrong – inspired by films like Blood Simple, Fargo, The Way of the Gun, Burn After Reading, and A Simple Plan. You’ll play ordinary people with powerful ambition and poor impulse control. There will be big dreams and flawed execution. It won’t go well for them, to put it mildly, and in the end it will probably all go south in a glorious heap of jealousy, murder, and recrimination. Lives and reputations will be lost, painful wisdom will be gained, and if you are really lucky, your guy just might end up back where he started.

The game can be easily extended with self-written scenarios (called “playsets”) and that’s what we did in this session: Create a playset with lots of themes from the software and technology world. We needed to come up with relationships between people (e.g. “Room mates”, “Shady hardware vendor & buyer”), Needs (e.g. “Hide my inability to write code”, “cut costs”), Objects (e.g. “server root password”, “the next iPhone”) and Locations (e.g. “The Watercooler”, “The Parking Lot”). The touchstone for relationships, objects & needs was: Can you imagine this to create drama and mayhem? The final product can be seen in this GitHub repository: https://github.com/haslers/fiasco-dev-edition

I attended one evening playtest session and had an awesome time playing a corrupt IRS investigator looking into irregularities in a payroll system programmed by a former nun, struggling with a disgruntled SCRUM master who wants to see the company burn …

This playful experience also made me think about what creates drama and mayhem in the real world. The list seems banal, but still is a powerful reminder of how awesome my workplace is, because these things are absent:

  • No learning culture: If you’re punished for making mistakes, you will try to hide them, blame others, etc.
  • Miscommunication & distrust: If you don’t understand other people or assume ulterior motives, this will lead to friction.
  • Not getting your needs met: If your workplace constantly fails to meet your needs for security, clarity (in processes and communication), trust, appreciation and autonomy, you will become unhappy.
  • Low moral standards: If the bottom line and personal gain (money, status, reputation) is everything that counts, everyone will lose.

Personal Kanban

Personal Kanban is about visually ordering your tasks and limiting the amount of tasks you’re doing in parallel. This session was an introduction and testimonial of people who use the method. Also, we created our own paper boards with different “swim lanes” where you can put small post-its with tasks. The idea is to always have it with you, the physical board being less distracting than your multi-purpose smartphone and more rewarding because how your brain works when you physically shuffle around post-its.

It was an interesting session, but the method is probably not for me, as most of my work tasks are already well-organized with Phabricator, a software that supports multi-column boards and different types of tasks. And for my personal life I’m content with using a mixture of calendar entries, well-formulated task lists and the Due app. Plus, I don’t tend to multitask.

But for days where not all work tasks are on the board (e.g. emails I need to write or breaking down a task into smaller ones), I’ll try to use my personal Kanban board as an alternative to a daily todo list and see if it sticks.

The cost of reuse

This was an open discussion about the dangers of reusing code and what can be done to reduce these costs. The initiator of the session is planning to write an article, so I will not elaborate on this, but just mention my three takeaways:

  • The topic of “Prefer duplication over the wrong abstraction” came up again.
  • We are already “re-using” lots of code in the form of software services like web servers, databases, etc. Also, for many programming languages standard libraries for routine tasks exist. Compared to what was available 20-40 years ago, we’re already doing a lot of “re-use”. And for those 20%-5% of actual code that we have to write ourselves, we seem to run more and more into diminishing returns.
  • “Don’t reinvent the wheel” is often said, but what exactly does “inventing” mean? Most of the time we have semi-clear picture of what we want and no software that exactly fits the picture. And just as there are 1000s of different wheel types with different performance characteristics for individual applications, there are many ways to solve a software problem.

Outside-In TDD

A demo of how to implement a “Fizz Buzz” program in a test-driven fashion by describing high-level collaborators. The end result was a rule-based system, where the implementation of each rule was trivial.

This session taught me to differentiate between “classist” and “mockist” approaches to testing and between “outside-in” and “inside-out” (or what I would call “bottom-up”) development. In an answer on the question of the difference of the approaches on Stack Exchange Programmers one answer is that there are two different schools of testing and development, one using classist, inside-out approach and one using the mockist outside-in approach. Another answer says that the approaches are othogonal, and you can also have classist outside-in testing and use mocks in your inside-out testing.

Introduction to the Fish shell

This presentation with Q&A session dazzled me with nice-looking prompts, the promise of easy prompt customization, intelligent, predictive command and parameter autosuggest and a Vi mode for editing commands. I’ll test the fish shell for the next 4 weeks the and see if I like it better than my current zsh setup.

Also in that session I learned a new command line tool: peco. It’s an interactive search tool for long lists, displaying only the list entries that match your search query. In fish you can use it to search your command line history.

Mob programming RPG

This was about “gamifying” a mob programming experience, giving each person specific tasks to do and giving an incentive (experience points) to perform these tasks. The rules and character sheets are good for making each person more engaged in the whole experience and even tries to level the playing field for people who normally aren’t comfortable in such a big group. However since the rules call for a 5-minute rotation of the roles of the “driver” (person at the keyboard) and the “navigator” (person who instructs the driver what to do next), there can be a strange mismatch between the playbook you keep during the whole sessions and the role you have for 5 minutes, because navigator and driver are both playbooks and roles. I have asked for clarification on that problem.

Code retreat

A code retreat is a series of pair programming sessions where the programmers work on a simple programming kata, each session with a different constraint. After each 45-minute session you have a small retrospective, the code is thrown away and you start a new session with a new programming partner. My insights from the 4 sessions we did:

  • It’s really important to have a prepared working environment (consisting of at least a code file, test file with a failing test and a test runner). Don’t waste valuable time with setup! At least if it’s not explicitly part of the kata.
  • Constraints really shape the produced code: When using constraints like “no functional programming, the return statement is forbidden” it’s obvious that you will choose a different design for your solution. But even outside factors like “no talking to your partner” or “work in 2-minute intervals, if your test is not green at the end, revert the code” have an effect. It can be a good reminder of Conway’s law: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations."
  • Don’t underestimate the complexity of the domain! The rules of our chosen programming exercise, “The Game of Life”, are very simple, but the concrete implementation can vary quite a bit: Use a more functional or more stateful object-oriented style, use value objects or language primitives, use 1-dimensional or 2-dimensional data structures (e.g. arrays) for storing the board, wrap around and the edges or not, etc.

Hopefully, I’ll be able to attend the Global day of code retreat on Nov 18.

Some interesting links I came across during the conference:

Conclusion

I’d very much like to attend next year’s SoCraTes. It’s a unique blend of very friendly, communicative nerds and a wide range of topics.