Single Threaded Development
I’m currently trying to evaluate an idea — let’s call it Single Threaded Development, where a single team would always work only on one ticket at most at any given moment. Perhaps someone already does it and has a nice name for it — but hey — reinventing the wheel can be cool sometimes!
You could have already read in “Async Remote” that at Arkency we try to follow these rules:
- have a single backlog
- you always take the first ticket from the top
- each developer works only on one ticket
- stories should be as small as possible while still delivering business value
Why do we do it? Some of the reasons are:
- It helps us spread the knowledge among the whole team. When a developer is not allowed to pick his ticket of choice, he’s less likely to gravitate to his own areas which he’s most familiar with.
- Small stories can also give you a sense of accomplishment at the end of the day and make it less likely that some important stuff is blocked by you — or, to put it differently, that your sudden absence will be a problem for the rest of the team.
- If you’re interested, you can read more about that in “Async Remote”.
Ok, but there still might be a couple tickets being worked on at a single moment. How about going one step further? But why would we do it? The problems we still have are:
- We still happen to have areas where some developer becomes particularly bound to a certain area of the codebase — i.e. the “knowledge spread” is not ideal.
- Unless you manage to finish a small story before the end of the day you still might happen to block the rest of the team.
- It might happen that stories are heavily related to each other — and when two developers are working on them simultaneously there might be some conflicts. This is even more likely to happen if we try to extract small stories.
We started talking about this idea when we recently tried a mob programming session (you can have a look at some video footage on Andrzej’s vlog). Mob programming might not be the most fortunate name, but it’s basically pair programming where the “pair” is more than 2 people.
Pair programming has many benefits. One of them is the aforementioned spreading of knowledge to the whole team. Mob programming takes it even further. Of course it has its obvious disadvantages. With mob programming it would be quite easy to practice this “Single Threaded Development” — you just mob-program all the time.
Let’s try to imagine how this could work in case of the team I’m currently working in: we’re a group of 3 developers working on 1 project in 2 timezones with 6 hours difference. Because we’re async, some of us might work quite unusual hours, like 4 am. We cannot assume that a particular developer will be there at a particular moment.
- Let’s say that you’re the first developer & you’re about to start your working session. You take the first ticket from the top of the backlog & start working on it.
- Before you’re finished, another developer starts his working session and finds that you’re already working on a ticket. So he joins you and you start pair programming on that ticket.
- If one of you finishes earlier, the other one continues.
- Now let’s suppose the other developer needs to finish his working session, but he has not finished the story yet. Because he’s been making frequent, well-described commits and over-communicated his findings to his teammates (e.g. on a slack channel) he might just unassign himself from the ticket and let others later start off from the place where he stopped. Over-communication is one of the other techniques described in “Async Remote”.
- If the other developer happens to have some code that cannot be committed because the tests are not passing, the code might as well be just discarded. It shouldn’t be a huge deal if you make frequent commits. Perhaps the other developer has a better idea later. Or you could just post your current diff to the slack channel — this way you’ll be able to pick it up later if the next developer happens to be yourself.
- Then, when another developer is about to start his session again, he’ll find that the ticket is not yet finished. He’ll go through the commit messages & other messages that were over-communicated and just continue where you left off.
- If at some moment, while pair programming, you’d happen to be willing to take a step back and go for a walk — why not — it won’t disrupt the process.
Of course it depends on your team size & timezone configuration. Smaller teams have a lot of advantages anyway.
In case of our team we’d still quite often have just one developer working. Sometimes pair programming would happen, mob-programming only occasionally. Depending on time, we’d reap the benefits of any of these approaches.
Maybe it’s not something to be applied as a rule to follow at all times — perhaps just to some certain phases of the development, like:
- working on a particularly difficult area which is quite crucial
- you’re not super familiar with the domain yet and there might be a lot of misunderstandings
- you happen to have a lot of tickets related to one area of the code & conflicts are likely
Does it sound viable? Could even more “async” (in the sense of being able to detach yourself at anytime without affecting the team). What do you think? Do you see any holes in this process? Would you give it a try?
PS!
It is that time of year — Black Friday is around the corner. Why not use this opportunity to make a treat for your career?
For a limited time you can save 40% on all Arkency books — not only “Async remote”! On checkout use coupon code: THAT_TIME_OF_YEAR
- level up you Rails and React skills
- become a recognized blogger
- transform your workplace
The choice is all yours! Hurry up — the offer is valid now until December 1.
