Thursday 21 November 2013

Starting a Software Craftsmanship Community

Two people that meet regularly are already a community. The first thing to know if you want to start a community is that it is much simpler than you think. You just need another person that is keen to meet regularly and a public space like a coffee shop or a quiet pub. That's it. You already have your community going. Everything else that follows in this blog post are just things that helped us to grow the London Software Craftsmanship Community (LSCC) from two people to the largest software craftsmanship community in the world, but they are not essential to have a great and healthy community.

Community website

This is an important thing. Don't try to run your community from a mailing list; make sure you have a proper website. One of the points of being part of a community is to know who else is in the community. As a member, I want to go to the website and see when the next events are. I want to be notified in advance about the events, and be reminded about the events one or two days before they happen. I want to know who else is going to the event. I want to place myself on a waiting list in case the event is full. I want to tell others that I'm going to the event. I want to see the profile of the people attending the event so I can have more focused conversations during or after the event. I want to have a mailing list where I can ask questions and engage in discussions.

The good news is that there are a few websites out there that, for an annual subscription, you can have all that. We decided to use (used by the majority of the Software Craftsmanship communities around the world) and I highly recommend it. Don't waste your time trying to create your own website, at least not in the first year or so. Focus only on the quality and content of your meetings. Don't waste your time doing things that are already done for you. Websites like will take care of all the admin work for you: controlling registrations, email, waiting list, reminders, etc. (In case you are wondering, I don't get any commission from, however, now that I thought about it, I probably should.:))

Your first meeting

Some communities started with a big first meeting. Others started quite small and without much noise. As you probably guessed, there is no right or wrong. In London, we decided to give a talk on Software Craftsmanship. The London Java Community (LJC) announced our talk to their members. SkillsMatter, the training centre where the talk happened, also announced on their website and for our huge surprise, 120 people showed up. The Paris Software Craftsmanship Community (PSCC) invited me to give a talk for their kick off meeting and they had more than 50 people.

It helps if you can have a big first meeting; potentially inviting someone that you know that can give a good talk on Software Craftsmanship but that is not really necessary. Many other communities started really small and now they are doing really well. It's important that we understand that a Software Craftsmanship community is not about numbers or well-known people. A Software Craftsmanship community is about passionate software developers sharing and learning from each other, regardless if there are 5 or 1000 of them.

Start with simple meetings

The simpler the meetings are, the better. When starting a Software Craftsmanship community, chances are that you won't have much help. We are all busy people, with families, work, and many other activities. If we make the job of organising a community a burden, we will end up giving up. To minimise the chances for that to happen, make sure that, at least in the beginning, your meetings are extremely simple to organise.

For almost one year, we just had one meeting a month: The Software Craftsmanship Roundtable. This meeting was limited to 30 people. Back then, I was working for [Valtech]( and they were kind enough to let me use their office space from 6:30pm to 9pm. They also paid for pizzas and soft drinks.

The Software Craftsmanship Roundtable

The Software Craftsmanship Roundtable is a very easy meeting to organise. At the start of the meeting, we ask all attendees if they want to give a lightning talk (five minutes for the presentation, two minutes for questions) or/and propose a topic for a group discussion. Attendees write their lighting talks or topics for discussion in a Post-It and stick them in a white board. While we are eating some pizza, people present their lighting talks. The facilitator, normally the community organiser, keeps track of time. Once all the lightning talks are finished (if any), we ask each person that proposed a topic, in turn, to give a 30 seconds explanation of what they want to discuss. Once all topics are explained, we take a vote. Every one raises their hands for the topics that they want to discuss (they can vote for more than one topic) and the most voted topic gets discussed. Sometimes we discuss a single topic in one night; sometimes we discuss three or four. Depending of how people vote, we some times split in two groups and then have a retrospective at the end. Every 30/45 minutes (use your gut feeling) you ask the group if they want to keep discussing the same topic or pick another one.

The great thing about the round table is that whichever topic is chosen, we know we are going to have a good discussion since the majority of the people voted for it. Topics can vary immensely, from tools and good practices to continuous deployment, from design and architecture to interview techniques, from how to convince teammates to adopt TDD to functional languages.

The overhead of organising a roundtable is very small. You just need to make sure you have a venue. If you don't have an office space, do it in a coffee shop or pub. Food is totally optional. If you have it, great, if you don't have it, it's OK. Don't let food sponsorship be the reason for not having a meeting. I'm sure people wouldn't mind to eat before or after the meeting and pay for it themselves. :)

Hands-on session

Hands-on sessions tend to be slightly more difficult to organise. This is the second type of meeting we introduced. Arguably, it should have been the first type of meeting to have but that was what we did.  Hands-on sessions require a venue where people can not only sit down but also have a place to put their laptops. That means that not always a pub or another public place can be a good choice. A proper office space is always a better option.

Over the years we had many different types of hands-on session. Some of them required a lot of preparation; some of them were dead simple to organise. We also had a mix of very experienced and not so experienced people running the sessions. They were all great.

For the first few hands-on sessions, keep it simple. Choose a kata, do it yourself a few times, and don't tell anyone which kata you've chosen. All attendees need to bring their own laptops with their favourite languages and testing frameworks installed. Have all attendees in a room and ask them to pair up with someone; preferably someone that they don't know or they never paired before. At least one person in the pair needs to have a laptop configured with their favourite language and testing framework. For people starting with TDD, it helps if they pair with people a bit more experienced. Give them time, between one and two hours, with a few breaks (5 minutes) for sharing, and towards the end, run a retrospective. While the pairs are working on the kata, walk around, observe what the pairs are doing, and help the pairs that are stuck. In the final retrospective, ask the pairs which approach they used, what they've learn, which technologies they used, etc. As you know what the majority of the pairs have done, you can poke people to share what they've done. :)

There are many different types of things you can do in a hands-on session but I'll leave them to another post.


A community needs to have a rhythm. A heartbeat. For example, our Software Craftsmanship Roundtable meetings are always on the second Tuesday of the month, at the same time, in the same place. Our hands-on sessions are always on the last Wednesday of the month. Code & Coffees are always every other Tuesday in the same coffee shop.

It's important that members of the community know when and where the meetings are going to happen so they can organise themselves to be there. A good rhythm keeps the community alive. When choosing a venue, make sure you can run meetings there every month. Once you run the first meeting in a new venue, it is much easier to run subsequent ones. Finding venues is not always easy, so make sure you don't need to do it every month.

In case you can't be in the meeting, make sure someone else can facilitate the meeting. Try never to break the rhythm. Having long gaps between the meetings will make people loose interest.

Make sure that you never have an empty calendar, that means, as soon as the a meeting is finished, you should have the date for the next meeting. People tend not to join a group if there are no meetings scheduled.

Technology Specific vs. Technology Agnostic

There are quite a few Software Craftsmanship communities that have many technology specific meetings. By that, I mean, they have a hands-on session to learn Erlang, or to try a JavaScript framework, or a specific NoSQL database. From what I know, that is working well for them.

In LSCC, we made a commitment from day one that all our meetings would be technology agnostic, and for the past three years we never had a single meeting that was related to a specific technology. There are a few reasons for that:

  1. We didn't want to alienate a single member of our community
  2. We wanted to focus on the foundations of software development and not in specifics of a language or framework.
    1. each developer can choose the language they want to use and who they want to pair with.
  3. If the community has monthly meetings and you (as a member) are not interested in the technologies chosen for the meetings, you may not attend the meetings for many months; you may even leave the community.
  4. We are fortunate to be in London, a city that has user groups and technical communities for all the main technologies out there. No point in doing what they already do well.

There is no right or wrong here and you need to use your gut feeling. Listen to the people coming to the meetings and try to provide what they want. However, at the very beginning, they probably won't know what they want, so you will need to make the call. Technology agnostic has better chances to attract more developers, from all sorts of backgrounds, which in turn will make the community more diverse. And that is exactly what we always wanted.

Focus on learning, sharing, and having fun

Learning, sharing, and having fun with like-minded people are the most important things in any technical community. As an organiser, make sure that this is your main focus. Growth is not important. Number of people attending the meetings is not important. Whoever comes is the right people. If everyone enjoys the meetings, they will invite their friends, they will tell other developers, so don't focus on growing your community. That will happen as a side effect.


In LSCC we have the LSCC Associates. Associates are some of the LSCC core members that I invited to help me with the organisation of the community. They are people that come to the vast majority of our meetings, are extremely passionate, talented, and fully understand the Software Craftsmanship ideology. The difference between them and the organiser and the associates is the level of commitment. Associates help whenever they can while the organiser doesn’t really have this option. Some associates will quickly step up and can easily become co-organisers.

As the community grows, you, as an organiser, will need help. Also, there is a limit for what you can do; the community needs variety. The community should never be about the organiser. The community should be about the community. Having a good group of people sharing the organisation should be one of your priorities as an organiser.

We have a separate Google group for the Associates where we discuss everything that is related to the community: ideas for a session, who is going to run it, new companies interested in sponsoring (venue, food, etc), new types of meeting, and many other things. At the beginning you may want to have one or two people to help you. As the community grows, you will need quite a few more.

Associates bring variety and enthusiasm. They keep the community alive and healthy. LSCC would never be so awesome without all the LSCC Associates.

Good neighbours

If there is any other user groups or technical communities in your city, go and speak to them. One of the reasons for the LSCC success is our proximity to other communities. The idea for starting LSCC happened during a conversation I had in one of the London Java Community meetings, and from day one we had the support from the LJC organisers. LJC, back then, already had more than 1000 members and they announced many of our events to the LJC members. We also have a good relationship with other local user groups. In the early days, we made sure that none of our meetings would clash with meetings from other user groups so we all could go to each other meetings.

Protect your community

It's your responsibility, as an organiser, to protect your community. As the number of developers grows, you will see many recruiters and marketeers approaching your community. They will try to use the community's mailing list to advertise their conferences, products, companies, etc. Protect your members and the community mailing list. At LSCC we don't allow any recruiters or people that are not directly involved with a software project to join. For that, membership is by approval only, and I do my best make sure that just people that can contribute to the community will join. We ask every member to write a brief description about who they are. We don't accept memberships where people don't write anything about themselves. A community is not a community if every person in the community doesn't have a profile. Currently I decline between 5 to 10 memberships a month. They are normally recruiters and people trying to advertise their stuff. Sometimes I even Google people and search them on LinkedIn to make sure they are really developers.

There is nothing that the community will gain with people spamming our mailing list. The only thing that will happen is that members will leave the community because of spam.

Have fun

I know that there is a lot in this post and maybe I made it sound far more complicated than it really is. Organising a community is a lot of fun and has many benefits. You will learn more than you can ever imagine and you will also be helping many other developers to learn as well. That, on its own, is more than enough reason to start a community.

Keep it simple and get more people involved. If you follow that, you will have a successful community.

If you start a Software Craftsmanship community, let us know. All of us from LSCC will be more than happy to help. I wish you all the best with your new community and, above all, I hope you have a loads of fun.

You can email me at sandromancuso at gmail dot com or find me on Twitter @sandromancuso

Friday 23 August 2013

Test Deafness

A few months ago I was talking to a musician friend of mine. He is also Brazilian, same age as me, and moved to the UK on the same year I did. As we were talking about music, I mentioned I like punk rock. He said he likes punk rock as well, but as a musician, he listens to a bit of everything. The conversation was going well until he asked me what my favourite bands were. "Legiao Urbana" is my favourite Brazilian band I said. "Seriously?" he said with a puzzled face. "They are rubbish, man."

As he was a friend (he became an enemy after that stupid comment), I thought to myself: How can I make him suffer for the rest of his life? Luck for him, I remembered that I was not a Brazilian savage anymore. I was British now and I had to act like one: "Oh, are they? Thanks for sharing that with me. Would you mind telling me what your favourite bands are? More tea?" He then named a few bands, including some Forró bands. Shock! Horror!! Blasphemy!!! I really wanted to kill him right there. Fuck the British citizenship. How could a guy, that also liked punk rock music, say that the band I liked was rubbish and then name some stupid Forro bands as his favourite bands?

After quite a long list of swear words pronounced in a very loud tone, I asked him to elaborate. All songs of Legiao Urbana, he said, are played with three or four chords maximum. Their lyrics are great, but they are very poor musicians. The Forro bands are totally the opposite. The lyrics suck but no one cares. Their are great musicians that focus on creating music for people to dance.

That conversation made me realise something really important. If you are a person like me, good music is related to good and strong lyrics. For a musician like my friend, good music is about the techniques used by other musicians when playing their instruments, regardless of the lyrics. For a person that likes to sing, she may appreciate opera, even if she doesn't have a clue about what the words mean.

But what does it have to do with tests?

You cannot expect to produce quality code just by listening to your test. If you don't know what good code looks like, you are pretty much test deaf. Musicians have a trained ear to listen to each instrument individually while the music is playing. They can also imagine, quite precisely, how different instruments could be combined to create new music.

Walking around asking other developers to listen to their tests, as if this advice alone would make them produce quality code immediately, doesn't work. It may make us look smart (or at least feel smart) but it does not really help the other developers receiving the advice. It's too vague.

If we want to produce quality code, we should study the concepts and techniques that lead to it: Domain Driven Design, Clean Code, SOLID principles, design patterns, coupling, cohesion, different programming languages and paradigms, architecture, just to name a few. Once we get a good understanding of all these things, we will have an implied knowledge about what constitutes good code. This implied knowledge is what may cure our test deafness, allowing us to listen to our tests in order to produce quality code. 

Tuesday 30 July 2013

My birthday wish list

Today is my birthday. Yay! And since today is all about me, I will choose what I want as a present. As a developer, here's what I want:

  1. I want developers to be empowered to do whatever they need to do to satisfy the real business needs and delight their customers.
  2. I want developers to be accountable for the decisions they make, and not by decisions that are made for them. 
  3. I don't want to see developers going through endless meetings trying to prove why they shouldn't use the technologies or architecture defined by an ivory tower architect. In fact, ivory-tower architects should be an extinct species (visit your nearest National History Museum if you want to see one). 
  4. I want developers to know the truth. If a decision was made because of political reasons, please tell us that that is the case. We will still be unhappy but at least we will find it easier to digest. 
  5. Although we are happy to justify and explain every technical decision we, the development team, make, we don't want to have any person that is not part of the development team making technical decisions. 
  6. I don't want to see developers working with technical people that think that their role is to define the architecture of a project. I want developers to work with people that focus on delivering the simplest solution to a problem; satisfying functional and non-functional requirements. If we can achieve that without writing software, even better. And no, that doesn't mean quick and dirty.
  7. In case we need to write software to solve a business problem, I want developers to craft solutions in a way that changes are embraced and the business will never be slowed down by technical incompetence.
  8. I want developers that can build applications that will provide a good return on investment to the business. I don't want to see applications being decommissioned after a few years because they became a pile of crap; the maintenance cost is so high that it is cheaper to rewrite. 
  9. I want to work with developers that are passionate and care about what they do. Every single day I want to speak to my colleagues and learn something new from them, the same way they should learn something new from me. 
  10. I want to work with people (not just developers) that embrace changes and provide business agility. I don't want to keep embarrassing myself every time I need to tell stakeholders that the small change they want will take a few months to be done (due to the crap application/architecture/process we have). 
  11. I want to work in a place where we can choose the best technology or tool for the job; without being told that we cannot do that because our people don't have the skills. "They need to be trained." (sigh)
  12. Instead of being told that we need to build a new feature or even an entire new application using specific technologies, we would appreciate if we were just given the business requirements. I would love to see that developers are trusted to provide the best solution for the problem.
  13. I would like to see the people behind all the bureaucracy and stupid processes being blamed by the damage they are causing. 
  14. I would like to see all the 9-to-5 employees being replaced by just a few passionate, talented, well-paid and empowered professionals. 
  15. I wish all companies recognised software development as a full career and not as just the initial steps for management. Yes, this is stupid.
  16. I wish that every organisation paying for a software project understood the principles of Software Craftsmanship and the importance to have real software craftsmen working on their projects. 

You may be thinking that I'm not being reasonable. After all, my birthday is almost over and of course no one will be able to give me all the things I want today, as a birthday present. You are right. I agree. And because of that, I won't add all the many other wishes I have to the list above. I could go on forever. 

The good news for me is that I'm really smart and I always have a plan B. Although I'm a disappointed that I won't get all these things for my birthday this year, my plan is to be a good boy for the rest of the year and maybe Santa will bring me some of these for Xmas.