Raising the Bar At SoCraTes UK

September 23, 2013

“As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft.”
The Manifesto for Software Craftsmanship

 

I am very glad to be one of the 70 developers and testers who attended the SoCraTes UK unconference. We were all hoping to work together towards the goal stated in the Software Craftsmanship Manifesto. The event was a success from this point of view; I think everyone learned more ways of developing software, from architecture, design, avoiding specific problems to functional programming, frameworks or programming languages.

 

The unconference started at 6pm on Thursday with a fishbowl discussion about the values of software craftsmanship. Sandro Mancuso and Samir Talwar, two of the¬†organizers of SoCraTes¬† and of the London Craftsmanship community, kindly asked me to be part of the first panel of speakers. We discussed many things, and each participant left with his or her own conclusions. From my part, I wanted to stress that we still don’t know what practices work to create good software consistently. Therefore, we should explore more practices and understand when our current practices don’t work. In order to do that, we need to master the practices that are the norm: automated testing, good design, architecture, pair programming, TDD/BDD as design and communication tools, clean code and probably others. That is only the beginning; a craftsman has to mindfully consider each context and pick the practices that make sense in that context.

 

Architecture Retreat At SoCraTes UK

Architectural Kata At SoCraTes UK

The second day of the conference started with Rachel Davies introducing the open space. The marketplace filled nicely with about twenty session, many of them running in parallel. I proposed two sessions that proved to be very popular: the Architecture Kata, attended by half the conference, and the Incremental Design session, an introduction to the concept much like my talk at ALE 2013. We had lots of interesting conversations about architecture and design; it turns out most developers don’t know the steps and thinking involved in doing architecture work, so I decided to do a follow-up session the next day. The day ended with a long evening of pair programming in the bar.

The third day of the conference featured again about twenty proposed sessions. I proposed once again two: “Architecture Step By Step”, for people who want to get an idea of how to do architecture, and “Design Process”, a conversation about how we do design. I had two key take always from these sessions. First, architecture can be taught and it’s very useful to developers, especially those working in a large application with multiple teams involved. Second, we need to develop new ways to build our “design sense”, much like you need to taste more wines to build your taste in wine. @sleepyfox proposed this metaphor, and I think it captures perfectly one of the issues I see when discussing design with programmers.

Since I tried to pair with people at conferences before SoCraTes and it didn’t work so well, I decided to throw in a little incentive: anyone who pairs with me will get a teddy bear. Ten people asked me for sessions but I only managed to pair with five of them. They have now a guaranteed pairing partner, someone who will be there when advice is required. We believe in Mozaic Works that teddy bear pair programming is nice and helpful, so we are glad to spread it to the world. And if the teddy bear can’t help you, we would be glad to do it.

 

I couldn’t attend sessions since I was busy facilitating my sessions, talking to people and pairing. I did get a glimpse of a few interesting statements that I want to explore:

  • Aikido principles can help with programming. @sleepyfox who used to be an Aikido trainer did a session on how he uses these principles in his programming work, which I find fascinating
  • Tests should cover behaviors and not classes. This is a key thing we teach people at our unit testing and TDD sessions, but it’s good to see they are confirmed by fellow craftsmen.
  • Functional programming is a way of expressing what you want to do and not how you want to do it. I think good design allows you to focus first on what you want to do and leave the implementation (how to do it) as a detail. The only problem I see with functional programming is that it tends to create hard to read code, at least for people who don’t know how to think in functional terms. It’s worth noticing that hybrid languages that mix object oriented, functional and dynamic features, are growing in popularity. Remembering this principle is always useful for creating good design in any language.
  • Dealing with legacy data is even harder than dealing with legacy code. Samir Talwar had a session on legacy data, and he told me about his problems with a 2GB csv file that contains badly formatted data with wrong types, bad encoding and without a clear purpose. To make sense of legacy code we at least have steps we know and we can take; making sense of data like that seems indeed a much more difficult problem.

To conclude, I did learn, practice and helped others learn a lot of things about our craft. Therefore, SoCraTes UK was a success that will allow many fellow craftsmen to improve their work and to strengthen relationships across borders. Some of this knowledge will go back into the workshops and learning sessions I create for other people, so that they can benefit from my improved experience.

 


Mozaic Works is proud to sustain SoCraTes UK 2013 through sponsorship. We thank all organizers and participants for a great event.

 

You can benefit too from our international experience. Let us know if you’d like:

  • Presentations from our internationally experienced speakers
  • Q&A sessions with our coaches
  • To pair program with our craftsmen and get a teddy bear
  • To learn more about architecture and design from our workshops and coaching

Categorised in: , ,

Leave a Reply

Your email address will not be published. Required fields are marked *