Third SoCraTes post in a row! If it appears as if I’m not doing anything else, well, it might be true..

Thursday 9 November until Sunday 12 November marked the third SoCraTes Belgium unconference. I’m not going to fully explain the concept, I’ve done that before and others can do that better anyway. Just a quick rundown of things I picked up and contributed to.

Marketplace

Click for higher resolution.

Java 9 module system

Java 9 is out for about two months now, so I hoped there would be others around that already had some experience and could help me with the first steps. I haven’t heard of anyone going full-blown on modules yet in their production systems, but a few people were experimenting on a reasonably clean kata, trying to modularize it.

I took away that the module path is a whole new system built next to the classpath, with the possibility to fully replace the classpath. Modules live on the module path and can only interact via the classes they explicitly expose by their contracts. When compiling and running Java code, you need to mention the module path next to the classpath.

I seems as if the tooling (Gradle, Maven, IntelliJ IDEA, …) is not fully up to date yet, or at least somewhat hard to use in a module path + classpath mixed world. For now we used javac and java from the command line, but that obviously doesn’t scale. Could be that we just didn’t do enough research yet on the tools.

Modules usually expose entire packages, hiding other packages (such as a .impl subpackage). This allows us to structure our code in packages that can freely communicate with other packages in the same module, without exposing implementation details to code outside the module. This is very different from how we used to organize and encapsulate Java code!

My thoughts: while I heard many people say we needed a new version of Effective Java for Java 8, I wasn’t convinced lambdas and streams were invasive enough to hugely impact our way of working - it mostly seemed like very welcome syntactic sugar that allowed a little bit more decomposition. I find it harder to wrap my head around the implications of the module system. It might be that I haven’t encountered the boundaries yet and need more exercise. Or it might be that the module system is actually very invasive in the way we design Java code, and if so, then I think a new Effective Java will help us (as an industry) save countless hours of frustration and rework.

Another part of the module system is the jlink tool, that allows a developer to build a native package that bundles the JRE, no dependencies needed. In fact, the module system allows us to only package those parts of the JRE that we need to run our application. This might be usable to solve an annoying distribution problem at work. On the flip side, if you distribute such an app to customers, you will need to update the app for security updates that are published for the JRE.

Thank you Guido, Doménique, Gert and Franky for your work and your explanations, it was at exactly the level I needed!

Architectural kata

We all have experience with it… Bad software architecture gets cursed at every day, while good architecture will support us and solve problems before we even notice them. But how can we become good at architectural decisions? After all, how many systems will you architect in your life? I would guess five to ten, at most. Can you claim to be good at something you have done less than ten times? And how many mistakes have you made along the way?

There is an obvious answer to this problem: practice.

An architectural kata (kata can be understood as ‘exercise’) is done in a few steps:

1. Divide attendees in groups, 3-5 people
2. Give each group a system to design, with a description from a customer side of view
3. Each group spends some time to create an architecture in whatever way they see fit. We took about 20 minutes but that was too short, I think you’d need at least 40 minutes to get through some hard decisions. Make sure there are physical artifacts of the architecture, on whiteboard or flipchart for example.
4. Review time! Each group presents their architecture to the rest of the group. Timeboxed constructive questions and discussion are encouraged.
5. After each presentation, everyone concurrently does a Roman vote (thumbs up/sideways/down) as feedback. We didn’t get to this, and I’m not sure it’s critical. On the plus side, it gives a voice to those that didn’t speak during the peer review step, but I’m afraid the non-nuanced voting system makes it hard for people to show their thoughts.

More on http://nealford.com/katas/, including some simple guidelines to get the most value out of this exercise. Mad props to Nelis who most expertly facilitated this session.

Effective communication

Aki introduced his session as follows: ‘I do trainings with parents to teach them effective communication with their children, and as we all know, this skill is also important in IT.’ Makes sense!

We were a small group of 5 people for this session, located in the couches in the bar, which made it very intimate. That was definitely a plus for this session.

A big part of communication trainings I followed emphasize sending a message, non-violent communication (NVC) being the big one. While this is important, and usually indeed the topic where we can practice a lot, Aki made it clear that the value of listening cannot be overstated.

One of the models (with the caveat that ‘there is no silver bullet model’) Aki uses is that ot the emotional rollercoaster, depicted above. When resolving a conflict, we want to discuss our problems rationally, and try to achieve a good compromise between parties. However, stating a request to another person will cause them to react emotionally to it. This will happen, no matter how we phrase the request, even if we do it through our own needs and feelings as prescribed by NVC. Vice versa, this will also happen to us when another party makes a request to us.

When emotions are heightened, there is only one way to move towards a rational state of discussion again: active listening. Making more requests at this time is not going to be productive. That means that, in a conflict situation, we should be prepared to alternate NVC with active listening, always being empathic with the other party.

Things I heard in passing and want to research more

• Angular components, in particular the notion of smart vs dumb components, as a way out of an Angular ball of mud. Introduced in AngularJs 1.6 but the idea should still be usable in earlier versions. Thank you Thijs!
• Liberating structures, even though the website is loaded with hyperbolic language, seems interesting. Liberating Structures is about meeting formats that are on the middle ground between static presentation meetings and unguided brainstorming, promising more productive and engaging communication. The Open Space format is itself a liberating structure. I arrived later at the session, two things that we discussed were the Occupy movement hand signals and the workshop format of Ritual Dissent.
• Clean Language is a coaching technique where you keep your own language clean of suggestions, yet try to guide the coachee to insight. The entire website sparks the imagination.
• Free monads, which are like monads but harder?

Things I facilitated

• The ‘doorbell challenge’, where I challenged attendees to make a software doorbell: push a button on one machine to make another machine make a sound, preferably routed through the public Internet. My main aim was to get people to write code from the start of the day, and to have a loosely constrained creative first session. Seemed to have worked.
• Regexes, Turing machines and the universe. Tried to share some of the theoretical computability knowledge I have, as I think it’s one of the more interesting bits of computer science. You can of course only give some vague intuition about this in an hour, and it’s hard to get feedback on theoretical lectures, but I think I managed to connect some concepts for the attendees. These topics also tend to spark philosophical discussion about the nature of complexity, emergence and the basic structure of the universe, which is awesome. Book shoutouts to Gödel, Escher Bach and to Complexity: A Guided Tour.
• Mars Rover kata with functional calisthenics. Ian wrote these down at SoCraTes UK a few years back and keeps being surprised that we seem to find them useful. Me, I’m not so surprised, there is good and bad functional design and we need to talk about it and practice it, just as with object-oriented design. I put up a request for feedback on the session via a feedback wall, but I completely forgot that I did this until two days later. This conference was way too exhausting.
• As evening activity I ran a Fiasco session with the dev ruleset we created at SoCraTes Germany. We had huge fun, as always with Fiasco. Thanks Bruno, Tim and especially Francis for his most excellent ‘Godfather’ character, fueling all the conflict.

Things where I tended to be helpful

• There where quite a few people interested in learning Elm, of which I happen to have some basic knowledge. It’s fun to see people discover how this well thought out programming language combined with a simple architectural model is a joy to use. Every undefined is not a function or TypeError: Illegal Invocation makes me sad now.
• There was a session on property based testing where I injected the things I had learned from Jan in Germany.

And some closing thoughts

This year I noticed the calming effect a certain few of the attendees have on me. These are people I look up to in our community, the ones where I consistently learn a ton from, and I see them interact with each other in a humble, thoughtful and empathic way. I find myself calmer and more open to others the weeks after the conference. I would like to find a way to extend this to the rest of the year. Will reflect on that.

My ticket to SoCraTes BE was paid for by DNS Belgium, my employer. We’re working for a safe and sustainable Belgian internet zone!