SoCraTes 2011

This event is about the sustainable creation of useful software in a responsible way.

It consists of two days of highly collaborative interactions, including Lightning Talks (on Thursday evening), scheduled sessions (on Friday), and a self-organized Open Space (on Saturday).

The event will be much like a retreat. We will be there for 48 hours to collaborate and share ideas.

Follow event on Twitter: #socrates11 or use this direct link

On the road at #socrates11 by Henrik Taubert (@htaubert) and Timo Yrjölä


I’m sitting in a train towards Berlin one day after the event has ended, trying to collect my thoughts from the camp as the shifting landscape flies by.

So, what is SoCraTes 2011 all about?

SoCraTes 2011 is the first international Software Craftmanship and Testing camp held 1.-3.9. 2011 in Seminarzentrum Rückersbach in Johannesberg nearFrankfurt am Main,Germany– or in numbers; ~55 enthusiastic and ambitious software craftsmen and –women.

Two main aims can be identified for the event:
To raise the awareness of software craftsmanship by bringing together people with the shared interest of “Fighting crappy code”.

To found a base for a software craftsmanship community in Germany.

The event was built up in two parts, a conference part on Friday, and open space on Saturday. Already the conference day had several very interactive sessions, with coding dojos, code competition and different talks on the agenda. The whole schedule can be found here:

And a description of all sessions and presenters can be found here:

A small inside view from and around SoCraTes 2011 in pictures

Thursday 1.9.:

Thursday evening started with some finger food and mingling in the bar, and after that the official opening session with presentations, lightning talks and good discussion.

The presentation round sounded almost like “Software Craftsmen Anonymous”, but you got quite a good picture of what kind of background and expectations everyone had.

 I was unfortunately a bit too tired to remember the details from the evening, and an early evening saved the rest of the conference for my part.

Friday 2.9.:

The session on Friday were either 60 or 90 minutes, where the 90 minutes sessions had a 30 minutes introduction and  longer “in depth” part. This format made it possible to actually decide as late as possible whether you wanted to stay the whole time or go to a parallel, shorter session after the intro. My personal reflection is that 30 minutes is a bit too short time to really get a good idea of the subject.

Specification by example, an introduction with Sergey Shishkin  (@sshishkin)

Recommended reading: “Bridging the Communication Gap” and “Specification by Example” by Gojko Adzic.


Specification is one of the core parts of a SW project. If it is unclear to the development teams you will end up with something that might resemble what you ordered, ie if you’re lucky. One problem many projects have is that although all parties, development, verification, product management want the project to succeed and have good intentions, they end up pulling in different directions.

Agile is not the silver bullet for this. Sergey gave an example where the agile transformation ended up in 4 weeks’ waterfall implementation. The solution was found in “Bridging the communication gap” by Gojko Adzic – Do the specification with all concerned parties, give concrete examples to highlight the main requirements and important details. This way you are able to also get in the non functional requirements from the start – build in quality.

The essence of software specification is :

  • Documentation; get it working for you, not for the process
  • Validation; not only testing, but also validate the business aspect and non functional reqs.
  • Communication; between team members and between teams, make sure everyone really understands the big picture, not only the task at hand.

Understand the business goals behind the customer requirements and requests, improves our focus. -> Good specifications remove the unnecessary blur, and bring out the clear picture; this is often an incremental process.

 Building Great teams by Uri Lavi @urilavi

Great teams consist of great people, so don’t underestimate the importance of the right hiring and interviewing methods. For technical roles you also want to check that the applicant understands business value, not only technical implementation details. Remember, one interview method does not fit all positions.

You want to get your good employees and team members to improve, and learn, create an environment that fosters learning.

Start by getting your good individuals to excel, and after that introduce the notion of craftsmanship to the rest of the team and organisation. Get the good spirit to spread.

Uri presented and explained the Dreyfus model as a comparison between great musicians and developers: It takes 10 years of 2-3 hours of daily practice to become a real expert in a field. Therefore, become expert in one field, but proficient in several fields of SW development. One way to get constant improvement is to do short, daily exercises with the team, eg katas, dojos, code reads etc.

The importance of having the right tools to do the job was also stressed in the presentation, but equally important is to really master your tools. Force the people to really learn the keyboard shortcuts by taking away the computer mouse for a day is one way of encourage learning. It also reveals some of the weaknesses of your tools.

One important point is to not do anything which is of no use. But remember to have fun, both at work and outside work. Learning and improvement should be made into a positive, social experience. E.g. arrange rotating book reviews, everyone as to review a book of their choice, alternatively co-review the same book, a couple of chapters each.

Soft Skills for software developers – Pierluigi Pugliese

Slides at:

Grow people, not only teams:
give room for growth, space to learn, space to interact

Experienced mentor, individual coaching for developers is rather missing.
Soft skills exercises:

  • Status games; (from improvisational theatre.
    • “judgemental remarks lowers your status”
    • Supportive statements lifts your status, formal or informal
    • “status games are everywhere”, importance of body language in conversations.
    • Productive vs. contra productive status;
    • Status in partnership, group dynamics, find the right “status” for the right situation to ensure productive partnership.
    • “you can’t remove status”, you can, however
    • “Another status”, ie. Try to change your own status consciously during conversation, teaches flexibility, but feels strange…
  • Think solutions (solution focused)
    • Solutions instead of problems
    • “All of the Facts are part of the problem, not the solution” – Wittgenstein
    • What would be different?
    • What resources did you use?
  • Transactional analysis
  • Ego States
  • Parent
    • Complementary transaction
    • Parent -> child
  • Adult
    • Crossed transaction
    • Ask as Adult -> reply as Parent to child, also implies status
  • Controlling vs. nurturing parent
  • Adapting child vs. free child
    • Tries to survive in the “harsh” environment (controlling parent)
    • Free child <-> nurturing parent
  • Exercise: discuss about anything, but answer with a crossed transaction
    • “what do you want to achieve, and choose accordingly, Think before reacting instead of just react intuitively”
  • Are you flexible enough in a conversation? Train your options instead of just try to follow recipes.

A message has 4  sides

  • About Facts –factual info
  • About me  — self statement
  • What I want — An appeal
  • Me vs. You — Relationship indicator

Try to use all 4 sides to make the communication clearer, more constructive. Try not to use self-statements only, or only facts.  All tools together gives more flexibility, use them

The Agile Architect by Uwe Friedrichsen @ufried

Slides at:

  • The importance of architecture for SW Craftsmen
  • What you need to think and care about regarding architecture
  • Architect is not a job, it’s a skill, and if your team lacks it you’re in trouble
  • The real goal is to deliver Wow!
  • Why?
    • Maximize satisfaction of all stakeholders
    • Minimize total cost
  • How?
    • Structuring (design) as an orientation aid
    • Alignment (Architecture)
  • What?
    • Achieve required quality
    • Manage complexity and changeability
  • Try to align problem and solution domain
  • Architecture <->software alignment
  • 90% of CRs are business oriented
  • SW developer’s skill is deep but narrow, concentrated to one problem domain
  • Architect’s skillset is more shallow but a lot broader, “a bit of everything”
  • Technology is “just” the starting point, a long journey to become an architect
  • Agility – people, Value, Risk management, “Use your brain!” (also applies to architecture)
  • Risk management, don’t make yourself irreplaceable.
  • What do I need to learn/care about?
  • Arc42-template; check the TOC. You must care about all, you choose how!
    • Seems like a lot, but you just need to stay focused, pick one at a time.
  • Use your experience to leverage changes that up front seems to destroy the current architecture. Decide as late as possible, remove complexity if possible.
  • Don’t introduce a framework for the sake of adding it. Should remove more complexity than it adds, otherwise it is just wrong.

Repair, Improvement and developer experience by Ade Oshineye

  • repair
    • it is by fixing things that we often get to understand how they work
    • make & repair form a single whole,
    • Static Repair
      • Do the changes by replacing a function
    • Dynamic repair
      • Change the object’s current form or function instead of replacing
  • Continuum of making and repairing
    • New code
    • Refactoring
    • Legacy code
  • Skill & community
    • In craftwork, people can do and improve
    • Can you transfer skill? Isolated expert problem. The Stradivari syndrome… He was great but couldn’t really teach his children.
    • Focus on teaching and learning instead of just acquiring skills
  • Refactoring != repair
    • Refactoring :Language specific issues that preserves part of the behaviour
    • Repair aims at changing the behaviour
    • User experience issues applied to developer domain.

Fish bowl discussion on SW Craftmanship movement in Germany

Uri Lavi from Israel and Sandro Mantusco from the UK shared their experiences from starting and running a software craftmanship community, and the participants continued by discussing both events and practicalities  around local SW Craftmanship groups. The end result was that some groups will start in at least a couple of cities in Germany.

Saturday 3.9.

The whole Saturday was built up around open space sessions, facilitated by Pierluigi Pugliese.

Due to the beautiful weather, many of the sessions were relocated to different parts of the garden. The sessions are mainly explained by pictures.

Emerging architecture:
The session was a continuation on “The Agile Architect” session on Friday, and the discussion went around top-down and emerging architectures; when to plan up front, and when to let the architecture emerge from the teams.

  • Identify the hard parts that are expensive to change
  • reflect, verify and stress test your architecure. How to stress test?
  • architectural refactoring, how to handle it?

Better Meetings:
What do we need to do to improve the meeting culture? Some key things: agenda, preparation, make all meetings optional -> the interested people will show up. Relocate the meeting whenever possible, try to get rid of unnecessary meetings altogether. See the image below for the outcome.

Soft Skills for SW developers continued…
This open space session was mostly about different games and ways to identify communication challenges  and problems through practical examples. We went through the four typical roles in a conversation, and made some practical trial by forcing certain roles on each and every participant. 

We also practiced on reading emotional changes through facial expression and changes in tone of voice. It was surprisingly easy after you had calibrated yourself against your partner.

The main learnings from the session was to be more observant and considerate of the people around you. And that many conflicts can be avoided by communicating consciously and not only based on feeling and first reaction.

The day and event ended with a wrapup and quick feedback session. Thanks to all the organizers for a great retreat.

-Henrik Taubert

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s