Something very exciting happened this weekend – a team of amazing talented women and I entered the 25-hour Hack Manchester 2018 hackathon, and we won Best in Show.
The problem is described here. You could approach the problem as a coding kata, which I’d love to do at some point – I didn’t have the time on this occasion. I ended up just solving it using pen and paper.
My solution is below. It won’t be the only solution, there are probably better ones out there that rely more on randomisation and less on patterns (or just use better patterns).
Don’t scroll down if you want to have a go at it yourself first!
So, I found a solution which works pretty well. I’m pretty pleased with it, and it’s nice and simple and neat.
The participants are split into groups of 15. The FRIENDS are in two groups of 15, both marked “FRIENDS” in the spreadsheet below. All the other groups are non-FRIENDS (well they might be friends, who knows? But they still don’t get to stay together – we’re mean like that).
It does mean that the people move in groups of 15, and they will stay in those groups. Not that they will necessarily know it. Because of the numbers, no matter what you do, they will keep encountering some people repeatedly (the maths of this is a separate problem which I’ve blogged about here). If you shuffle the list and assign the non-FRIENDS to 28 groups of 15, hopefully they will already be mixed up with people they don’t know, so they needn’t be aware that they have been grouped. I’ve labelled the groups B1 to O1 and B2 to O2.
What it does mean is that each group of 15 never encounters another group of 15 twice – they meet a different two groups in every session. So everybody meets 30 new people in every session (I haven’t actually proved this but I’m pretty confident).
(Since I came up with this, I’ve realised I can improve it quite a lot so that people don’t have to stay with exactly the same 15 people – scroll down to the bottom to see this improvement).
So, there are three groups in every session, like this (this is my actual solution):
Here’s how I did it:
First, split the non-FRIENDS people into two halves, 225 in each half. The first half has groups B1 to O1, and the second group has B2 to O2.
For now, we will also split the FRIENDS into two groups, A1 and A2 (this was my “Aha” moment, all made possible because of the fact that you have duplicate workshops in each session).
So for each half, we have letters A to O. For the first session, we just spread them across the 5 workshops: ABC in the workshop 1, DEF in workshop 2… etc.
For the second session, the first group in each triplet just shuffles along to the next workshop. So A is now in workshop 2, D is in workshop 3, etc.
We keep doing this all the way down the sessions, for the first group in each triplet.
For the second group in each triplet (B, E, H, K and N), instead of shuffling them on by 1, we shuffle them 2 workshops along. So, B was in workshop 1 in session 1, then we add 2 so they are workshop 3 for session 2, then add 2 again so they are in workshop 5 for session 3, keep going (wrapping around) and they are in workshop 2 for session 4 and workshop 4 for session 5. Do this for all the second groups (B, E, H, K and N).
For the third group in each triplet (C, F, I, L, O), add 3 on each time. So group C has the following workshops: 1, then 4, then 2, then 5, then 3.
Do this for all of those third groups.
This is what you get:
Now, at this point you have a problem: Your FRIENDS group have been split into two groups of 15. But ooh! Look! You did the same thing for A1 to O1 as you did for A2 to O2!
A1 and A2 are always in the same workshops at the same time. So you can move A2 into the same workshop as A1, and swap another group out into the spot left blank by A2.
I then renamed both A1 and A2 to “FRIENDS”, and that’s how I arrived at the spreadsheet pasted above.
POST SCRIPT (also see separate maths problem here):
Since I came up with this, I’ve realised I can improve it quite a lot so that people don’t have to stay with exactly the same 15 people:
The “FRIENDS” group mess it up a bit, but in most cases you’ll have parallel groups moving independently in duplicate workshops, eg when group C1 is doing workshop 3, group C2 will be doing the other duplicate of workshop 3.
Well… If each group of 15 was split into two sub groups of 7 and 8, then they could shuffle around and meet each other. Also this could be done dynamically.
So, for instance, you have C1a (7 people), C1b (8 people), C2a (7 people) and C2b (8 people).
In session 2, swap C1b and C2b so now only 7 (or 8) people stay together. Do the same with all groups (except those affected by the “FRIENDS” group).
In session 3, put C1a with C2a and C2b with C2b. This adds up to 14 and 16, so somebody will have to switch sub groups. In sessions 4 and 5 you could split them again, but this time randomly. As long as all the Cs are doing the same workshops, you can split them how you like. Ultimately they will all meet each other so they’ll still have repetition with 15 people overall, but it won’t be the same 15 people in every workshop. And they’ll still get 30 brand new people in every workshop.
I think this would make a great code kata, although I found a solution using pen and paper. It is a real problem, which my friend is genuinely trying to solve.
She is organising a conference. She has been given the following very interesting, and non-negotiable, requirements:
There will be one day of workshops. There are 5 sessions and 5 workshops. There will be 45 people in each workshop. There are 450 conference attendees, so each workshop is duplicated in each session. That is to say, during each session there will be ten actual workshops, but only five distinct workshops. So workshop 1 is happening simultaneously in two different rooms, as are the rest of them.
The aim is for participants to meet as many new people as possible. So for each attendee, we want to minimise the number of people in each workshop that they have met in a previous workshop.
We also want every attendee to attend every workshop.
And there is one more special requirement: There is a group of 30 attendees, we’ll call them FRIENDS, that must be kept together at all times. So in their workshops, there will be a rotating number of 15 extra people. They must meet a different 15 people in every workshop.
I have a solution for this, but I’ll post it separately in case you want to try it for yourself.
Here is a diagram that might help you to visualise the problem:
There is an associated maths problem about the permutations and probabilities involved, here.
A colleague and I had a conversation about moving developers between teams, and associated worries about causing disruption and losing knowledge / expertise.
I told the colleague about the book I was reading – Joy, Inc by Richard Sheridan, about a company in America called Menlo Innovations. Richard describes how at Menlo, they can easily move engineers between projects with minimum disruption. This is because they are used to pairing and knowledge sharing, they all adopt the same working practices, and no one person has code-base knowledge that isn’t shared by others.
Below are some extracts from the book that I think are relevant to this conversation. The basic premise is that pairing, a culture of learning and a focus on joy in the workplace all help to ensure that there are no towers of knowledge or lone genuises, and everyone can easily switch from one team to another.
I should add that I emailed Richard to ask for his permission to post these extracts, and he was extremely helpful.
Joy, Inc. excerpts are Copyright 2013, 2015 by Richard Sheridan. Used with permission. All Rights Reserved.
Chapter 12, Scalability (starts p194):
Brooks’s law is the motto of a broken hero-based culture that still largely exists in software development today. It states that the onboarding cost of a new person, particularly to a late project, far exceeds the potential contribution of that new person within the first few weeks or months of joining an effort. If a project is already late, then adding someone to it will make it later. The only alternative to a missed deadline then is an eight-hour-per-week death march for the current team.
… If you have no systematic means of transferring knowledge in a way that can quickly lead to mastery and autonomy for the new person, Brooks’s law applies to you, too.
…At Menlo, we have defeated Brooks’s law so many times that its premise is but a faint reminder of a quaint time in our industry’s history. Our entire process is focused on breaking this law. Pairing, switching the pairs, automated unit testing, code stewardship, non-hero-based hiring, constant conversation, open work environment, and visible artifacts all topple Brooks’s assertion with ease.
…Our pairing system, particularly the part where we switch the pairs every week, gives us a chance to practice scalability even when we don’t need it. We borrowed this concept from the airline industry (there it is called cockpit resource management). By switching pairs every week, we practise onboarding a new team member into a project even if the project stays the same size. We also practise onboarding new team members by bringing in four to six international interns annually.
…As the basic planning and coding practices are consistent across all projects, there is no need to train these new team members in any project-localized or personality-based methodology. The fact that everyone on the team has a shared belief system in our approach ensures there is no friction around these shifts in project assignment.
…Because the team is not based on towers of knowledge, because no one developer owns part of the code, because everyone has been working in all sections of the code, and because the people who have moved to another project are still in the same room and within eyeshot and earshot of one another, there is no meaningful loss of information about the project.
…How does a team get back up to speed when the project has been placed on the back burner for months at a time? … This falls back to documentation and standard work process. The automated tests provide the first foundation. They catch misunderstandings as new coding changes happen. If a programming pair returns to the project, makes a change they believe is okay, and one or more of the unit tests fail, the automated tests inform the programmers immediately that a mistake was made. This begins to refresh their memory of decisions made in the past. Code stewardship is also a big part of this, as the code has been viewed and adapted by so many different people over time that it has evolved into a body of work that reflects a commonly understood expression of intent, not a convoluted expression understood only by the hero originator and no one else.
…At Menlo, we measure cost against the final product: joy. We want the end users of our work product to thank us someday and tell us they love what we created for them. Most software teams never even get close to this effect. Can you measure something as intangible as joy? Perhaps not exactly, but you can measure usage, long-term quality, market share, customer satisfaction, market dominance, end user delight (at least anecdotally), and a lack of support calls. If we establish the team’s accountability to get these kinds of results every time, we get to joy.
Chapter 3, Freedom to Learn:
Assigning pairs and switching them each week helps avoid a variety of typical team ills that could interfere with learning outcomes. For example, it prevents team members from feeling alienated by another team member who may not have a particularly outgoing personality. It may not be a personality problem at all, just normal human shyness. We avoid cliques forming, as everyone gets a chance to work with one another.
We’ve found that people are more likely to engage in a casual pop-up conversation with others whom they’ve previously paired with for forty hours. This time spent together dispels a lot of misconceptions about one’s fellow teammates. Once you spend forty hours in conversation with another human being, you are going to get to know that person in a deeper way than a general impression could ever accomplish.
Working in pairs also provides an emotional safety net for our employees. As much as they are stretching the boundaries of what they know, they are also testing the edges of what is ‘safe’ in a work environment. When a new technology or process or domain is introduced, there’s always the prospect of fear creeping in, a natural human response to the unknown.
Imagine a six-year-old child on an unfamiliar walk near the edge of a deep, dark forest. The child will stand frozen and frightened, unable to move forward. But place an equally frightened six-year-old friend beside him and together they may confidently travel this unknown space together, hand in hand. Just like the buddy system we learned in childhood swim classes, pairing helps us move into the unknown with confidence and courage, comforted by the safety such a system provides.
We don’t tolerate towers of knowledge or lone geniuses at Menlo
The hidden benefit of giving your team members the freedom to learn is that, eventually, they will embrace the idea of taking the time to teach. Knowledge isn’t kept away in secret personal vaults like the crown jewels of little kingdoms. The workers on your team become more valuable as they learn new practices; they also become more flexible. Some conclude that this diminishes each team member’s unique value and turns each one into a cog in our little software factory machine. Usually, in the very next breath they tell us how amazingly valuable each of our team members is because of his or her mastery of so many different technologies and domains. This can happen only when you truly believe your team members are equally valuable and equally able to learn and carry certain knowledge.
Pairing is the atomic element of our learning organization. It produces a joy in learning that most of us haven’t experienced in years, perhaps since elementary school, when everything was new and all we had to do was absorb it.
Joy, Inc. excerpts are Copyright 2013, 2015 by Richard Sheridan. Used with permission. All Rights Reserved.