Some notes and impressions from SoCraTes UK 2016, an unconference on software craftsmanship and testing.

This was my first Socrates, and it was excellent - an intense but overwhelmingly positive and inspiring weekend of discussions about improving software and the industry. The open-space principles (especially “Whoever comes is the right people” and the Law of Two Feet) meant that everyone was engaged and open to discussion - it effectively removed the subtle barriers to joining and leaving conversations that you’d normally find in a large group.

Discussion: Coaching technical practices

• Introducing new devs to design patterns too early is confusing - they don’t make sense until they’ve seen the problems that design patterns solve. Concept of code smells is much more useful.
• First of three sessions of the day to mention the the Transformation Priority Premise, which I’d never heard of but turns out to be a really interesting suggestion for choosing what test to write next in TDD

Workshop: Bacon Snake

• Based on this Github repo
• Very fun introduction to functional reactive programming. I had to duck out half way through, but I want to come back and finish the exercise

Discussion: Property-based testing

• There is a Java library for this: junit-quickcheck (as well as David MacIver’s Hypothesis Java)
• Idea of Approval tests
• Someone mentioned a conference talk about how Volvo uses PBT - I haven’t watched it yet but I think it’s this one on Erlang QuickCheck
• Can (and should) you be doing TDD with PBT? We tried this as a mob later using the diamond kata and came to the conclusions:
  • We don’t have good instincts for picking the next proper test to write (this was before I’d seen the block post above on the Transformation Priority Premise, so need to think about that a bit)
  • The diamond kata is easy to write example-based tests for and really fiddly to write PBTs. I’d like to try a few others to get a feel for it.
  • People coding while drunk are even less likely to read the error message
• There’s now a property based testing channel on the Software Craftsmanship Slack to continue the discussion
• PBTTDD is a terrible acronym

Discussion: Giving confidence to developers

• Setting expectations is a big thing: we tend to dump devs onto projects without making it clear what we expect them to achieve, which causes people to worry that they’re not fast enough because they’re not as experienced as someone else
• If more experienced people don’t want to help the newer devs because they just want to get the code done, that’s a team smell
• Beware introducing new techniques (can’t remember if we were talking about pairing, TDD or something else here) on production code - it will slow things down at first, which will make people question its value if they don’t realise that it will help in the long run. Try it with exercises first.
• Go round everyone in stand-up and say something you learned since yesterday
• People find mobbing really useful for knowledge-sharing. We don’t currently do enough pairing to make this a reasonable next step, but I want to try running a (voluntary) mob for an hour or two a week on some tricky problem on the project to see if it helps.

Presentation: Outside-in TDD

• Franzi’s step-by-step example is really great

Discussion: Smells like team spirit

Are there common early-warning signs of deeper problems within a team?

Smells we came up with:

• Someone goes on holiday and everyone else gets less done
• Someone goes on holiday and everyone else gets more done
• Too much work-in-progess, which might be because:
  • People feel they can’t say no
  • People are just getting their own stuff done, rather than helping each other
• The same issues keep getting revisited
  • Might mean there’s no conscious progress for coming to a decision
• In standups, people address their comments to the same person (usually the manager) or feel they have to account for their time, even if it’s not relevant to everyone else
• People are always late to meetings
  • Might mean the meetings aren’t relevant, or maybe they don’t know how much it disrupts everyone else
• Corridor retros (important stuff gets overlooked in retros, but gets discussed in semi-public elsewhere)
  • Try running safety checks before the retro. We do this on my current project, and I suspect (but don’t know) that it helps. Be careful what you do if the safety check highlights a problem: try rerunning it without the manager, rather than putting people on the spot to answer why they don’t feel safe!

Workshop: Functional programming in Scala

• My laptop is old and is no longer capable of installing SBT in less than 30 minutes. Not of much use to anyone else, but a bit of a wake-up call to me…
• @twestmacott on Java vs Scala: “Scala is a language in which the range of good to bad is wider”

Workshop: CQRS with ES

• Fascinating session - we implemented a small Twitter service with a CQRS architecture (though we only got as far as the C because of time)

Design sprints

• User feedback: define what success looks like before demoing something to real users

Discussion: Diversity

• UK is the worst in Europe for numbers of women in engineering professions (10% compared with Latvia’s 30%)
• Just assume that someone at a tech conference is a dev. They’ll tell you if they’re not. Yes, this has happened to me.

General ideas

• Make a word cloud of your class names to see if you’re naming things after domain concepts or if you have lots of factories and helpers
• Elm and React both sound worth looking into
• PLIBMTTBHGATY (Programming Languages I’ve Been Meaning To Try But Haven’t Gotten Around To Yet) - meetup in London on the 2nd of July, which I’m sad that I can’t make