Mob and Pair Programming and Concurrency
Anyone who has done any significant concurrency programming knows it is fraught with pitfalls. You can have bottlenecks, write locks, dirty reads, and read locks.
Brief Overview of Concurrency Pitfalls
At a high level, there’s three main pitfalls when writing concurrent code:
- Lost changes
- Dirty Reads
- Liveliness
Lost changes occur when two threads write to the same resource. The last one in wins.
Dirty reads happen when a thread reads from a resource before another thread updates it. Now the first thread is making decisions on incorrect data.
Liveliness is how responsive threads can be when you start locking resources to prevent the previous two issues.
Map Concurrency Pitfalls to Solo Development
Concurrent task work, also called solo programming, is like concurrent application development and suffers from similar pitfalls.
Lost Changes
Modern version control tools have eliminated lost changes, but they cannot eliminate lost knowledge and expertise. If Joe and Hank each spend a week or two hammering away solo at module A, when and if they sync up, one, if not both, are going to have to throw away some changes. By each taking off in a different direction and not collaborating, they each waste time implementing their own solution when they could have collaborated on a single one.
If Joe and Hank had paired on module A work, they would have continuously synced up, eliminating wasted work and rework.
Had the whole team mob programmed module A work, everyone on the team would be familiar with the changes and no knowledge silos would develop. The expertise of each team member can contribute to the final implementation.
Dirty Read
(Dirty Read) For example, if Joe is well versed in the Fiddle module, but Karen spends a week making solo changes, Joe’s knowledge has been lost and is out of date.
Liveliness
I see this all the time when I first start coaching an agile team. All the stories and tasks have dependencies. We can’t do file transfer until we get authentication. We can’t do update until we can do create. In the end, most dependencies are imagined more than they are real.
Mob programming makes all that moot, however, because only one task is worked on at a time. So you say you must have authentication, then let’s do authentication.
Removing concurrency from task completion makes dependencies not matter.