By Jason Kerney

Humans are notoriously bad at multitasking. Development is a complex undertaking that requires true multi-threading of tasks which all have interdependencies. A developer needs to balance architecting a solution, writing code, managing cross-project dependencies, and maintaining previous projects. Circling around actual development are issues of ensuring that requirements are correct, updating documents, managing requirement cross-dependencies and deciding which technology represents the best way to deliver the desired solution to the customer. These are just a sample of the things that a developer is expected to do. What is worse is that all of this is happening at the same time.  It is time for a multicore  developer. I have witnessed “Mob Programming” provide a solution to the need of a developer to multitask.

There are tons of benefits to well-written code. However, people’s ability to perform any task changes from day to day, and even hour to hour. So the quality of code that someone writes is the average of their peaks and their valleys. With the mob, since there are multiple eyes on the code, the code is written at the highest capability at the time. Since you are now averaging the rates of the highest performer, your overall average is significantly higher. The code my team has produced is the cleanest, easiest to maintain and the DRY-est code I have ever seen.

A team remembers at a higher fidelity than individuals or even the sum of those individual’s memories. Psychology has a theory known as “Transactive Memory” (http://en.wikipedia.org/wiki/Transactive_memory) which describes this process. I have seen the mob remember discussions with product owners about features we implemented a week after initial discussions complete with minute details. This leads us to implement the correct solution the first time and makes our business analysts feel like valuable partners because we “get” their intentions quickly.

Transactive memory has led to other benefits as well. The team notices when logic repeats, even when the instances of the logic have months between the initial writing and the current process. This happens even with uninteresting bits of logic or trivial solutions. Again leading to a cleaner overall design.

Being able to examine software design at multiple levels is a must for a developer. Architecture cannot only be considered at the application level any more. There is the architecture of the class we are working on and design considerations regarding that implementation. Individual classes and projects of classes does not cover everything either. We have to consider the design of our whole product suite. Everything a developer creates has shared knowledge, routines, and libraries. Lastly, there is the data architecture with relationships in data and data storage. Developers have to constantly be monitoring all of this. They have to be thinking how a change in one area will cascade through all others.

The mob has an interesting approach to this. There are multiple people participating in the creation of the code base at the same time. Since there are multiple people, each can, and often does instinctively, focus on different aspects of the architecture. With every decision, multiple people consider how that decision affects different parts of the whole system. Then, guided by each, we dive down and work through the changes at all levels. Everyone, though focusing on different parts, keeps the current context in mind and never loses sight of why these changes are made.

So, like I said, it is time for a multicore  developer. Everything I mentioned is constantly happening. The demands on developers today is that they have to not only approach all of this, but they have to be able to do it all at once. Most good developers try to combine tasks using clever tricks or rotes, smashing concerns until they can fit them into bite-sized chunks that somewhat relate. This falls apart as soon as something becomes different or complex.

For us, we found a different solution. The mob allows us to function as a single developer but with multiple cores. We are able to do everything I talk about above and more. We also have the benefit that all this is happening at the same time without distracting us from our current goal on hand.

I would like to state that “Mob Programming” should not be thought of as the only answer to the multicore programmer problem. I would even say it is probably not for everyone or every company. There are a lot of factors that allow it to work with my group. However, I do believe the problem of the multicore programmer is a real one. I also believe this problem is becoming more prevalent as time continues. I cannot wait to read or hear about how other people solve this problem.

Thank you,

R. Jason Kerney