What Is Mob Programming?

Simply put, mob programming is about getting together with at least three developers and start coding on a single keyboard. At any given time one developer is actually typing, the ‘Driver’. All other developers take the ‘Navigator’ role. They all review, discuss and describe what the Driver should be doing and the Driver narrates. The roles are swapped very frequently to keep everyone fresh and engaged. It’s the ultimate form of collaboration and peer review.

Mobbing During Lock Down

So now you know that mob programming is about live coding together on the same piece of code. But how do you do this when everyone is working remotely during this pandemic. With my current team we decided to give it a go regardless. There’s excellent online collaboration tools available these days, so it must be possible to exercise mob programming fully online. We’ve practiced for three days in a row in a mob programming hackathon. Below I’ll describe my experience.

My current team consists of five developers, two full stack and three backend developers (including myself). We were all very excited about this online mob programming experiment. The first thing we needed to decide on was which tools to use. We already knew we would use Slack or Zoom to setup a video call. It’s very important to be able to talk to each other and read each other (e.g. facial expressions). Since we were all using IntelliJ as an IDE we saw roughly two options:

1. Use the built-in screen sharing Slack or Zoom offers
2. Use an additional collaborative development tool that integrates with IntelliJ (e.g. Code With Me or CodeTogether)

Why We Needed More Than Screen Sharing

We all already had experience with pair programming using screen sharing tools. In general it works pretty well, but there are a couple of down sides.

• Switching Driver is usually not a smooth experience. The current Driver has to stop the screen share before the new one can take over. The code has to be synchronised using VCS and the new Driver has to lookup the place to continue coding. Due to this “burden” switching roles won’t happen often enough. Drivers become fatigued and Navigators zone out.
• It’s hard to Navigate when someone else is controlling the screen. As a Navigator it’s usually not easy to just point at the place on the screen you want to make a remark about. Anybody that shared code using screen sharing before, e.g. during a code review session, will recognise the frantic screams: “CAN YOU PLEASE STOP SCROLLING”.
• Screen sharing is usually draining resources such as CPU and network bandwidth.

Let’s Take This To The Next Level

The short comings mentioned above made us look beyond screen sharing tools. Someone in my team mentioned Code With Me and we decided to try that out for a change. Code With Me is a plugin for IntelliJ developed by JetBrains that offers simultaneous editing. One developer hosts a session and shares a link for others to join. When joining a session (in the background) an IntelliJ Client is downloaded and started, allowing you see and edit the code on the host’s IDE.

Five Developers, One Editor

Besides a few connection problems at the start the first experience was great. Switching Driver is fast. Very fast. In fact, there’s no switching involved at all. All participants have their own cursor and can write code. This makes it really easy to get ideas or suggestions across. There’s no need to dictate the Driver, you can just type it yourself. Everyone felt very engaged and we were off to a great start of a fruitful coding session.

In all fairness the simultaneous editing also has some pitfalls. It can be quite chaotic at times. The clear separation of the Driver and Navigator role is gone. This can lead to confusion. “Do you want me to type it or are you going to?” In the chaos Navigators might forget they can jump into the action and start dictating others again. Or they zone out in the midst of the anarchy.

So it does require a certain discipline from all participants. Be patient. Give others time and space to show their ideas. Make sure everyone stays involved. If you notice people start dictating, offer them to write down their suggestion instead (This happened frequently in our case, probably also because of getting used to this new form of collaboration.) When someone has been quiet or inactive for a while, try to get their involvement again by asking for an opinion or make an explicit switch of the Driver role.

Another thing we noticed is that when joining a Code With Me session, you’re stuck with the key bindings of the host. It might definitely impact productivity if you are not able to use your favourite short cuts. A counter measure could be to try to align your IDE setup as much as possible within your mob. Maybe it could also be a nice feature of the plugin to ensure everyone can use their local key bindings. This might already be supported by other tools or plugins which we haven’t tried yet.

Lastly, there were some occasional network hiccups and synchronisation glitches. Sometimes code you already typed disappeared as a result. This was a little frustrating, but overall didn’t have a large negative impact on the total experience.

It would be great to try out alternatives to Code With Me, e.g. CodeTogether, to see how they compare. If you have any suggestions for tools to try, please leave them in the comments!

Conclusion

We’ve practiced online mob programming for three consecutive days. It has been a quite intense, but mostly exciting and fun experience. Everyone felt energised and inspired. We were all happy with the end result as well and felt real ownership of it. Everybody contributed by writing and reviewing code. We kind of embedded peer code review and knowledge transfer in the coding process, while that usually is a separate and additional activity. It almost felt like cheating and skipping one step in the development process.

The whole experience made us realise that this is something we’d like to do more often. It was great to see we could reach this level of collaboration during the COVID-19 lock down.

Thanks for reading my story. I’d love to hear your thoughts and own experiences as well as suggestions to improve online mob programming!

I’m grateful to learn from my daughter. Be able to see how the brain develops and picks up new concepts, skills and words. Nowadays, I enjoy to sit down and watch her play. As a parent, I also need to help her to achieve her autonomy: emotionally, mentally and physically. It is the job, and my wife and I are navigating through it. There is not a guide on how to parent, and we discuss what is working and what is not working. Sometimes is just not the time for a new skill, other times our daughter doesn’t develop an interest for a particular activity. Well, we are all different, and that is what makes the world colourful!

Collaborative modelling is not only an essential practice in Domain-Driven Design for creating a shared understanding of the domain. I believe it is vital in building sustainable and inclusive quality software. Covid-19 has constrained us to move collaborative modelling sessions online, and for almost everyone, this is uncharted territory and can be quite overwhelming. In these series of posts, I hope to give people some guidance and heuristics to start doing more of collaborative modelling in a remote world so that we can build more sustainable and inclusive quality software. We start this series with a practice that can make or break a collaborative modelling session, a Deep Democracy check-in.

Context Map was the first visualisation for the Bounded Context pattern from Domain-Driven Design. In a nutshell, it is a map of the different Bounded Contexts and their relationships. I tend to create a Context Map during or after a Big Picture EventStorming. Changing perspectives can be helpful, to challenge assumptions and get the best of different techniques.

However, sometimes it is hard to reach a consensus on the Context Map. I often operate in brownfield projects, with large organisations. Although people agree with the different bounded contexts, it is a process that takes time, and most significant energy. Which can lead to fatigue towards the method, and at the same time raises exciting patterns in the behaviours. But this blog post is not about emergent behaviour. 🙂

Chaos Engineering is a practice that has its roots at Netflix. It born from the challenges of moving their workloads from the data centre to the cloud; the transient nature of the cloud affected the way that they build and operate a system at scale. The initial project was called Chaos Monkey, and it has almost 10 years.

Since then the community grew, fueled by Netflix practitioners. Today there are commercial and open-source tools, and we can see more initiatives in different communities. The technical practices had matured, and the knowledge started to spread in the IT world.

However, it is deemed perceived as a technical practice. Can we leverage Chaos Engineering as a management practice?

Team Topologies is the work of Matthew Skelton and Manuel Pais, and I use it as part of my job. From a sociotechnical perspective, a team-first approach is paramount for any organisation and helps to decrease the accidental complexity. As such, I’m often asked “How can we operate in DevOps?” or “How can I have a reliable service to deliver value to my customer?”.

Recently, I was invited for a podcast interview by my brilliant colleague João Rosa. It was my first podcast interview (yes I was excited and nervous), and it has been keeping my mind busy ever since I received that calendar invite. The idea was that we would discuss a heuristic and see where we’d end up after 30 minutes. The heuristic for my interview was ‘If something is too complex to understand, it must be wrong.’ 

My first reaction was “Yes! That’s actually a heuristic I regularly use myself; what a coincidence!”. As hours and days went by, I started to notice that something was changing in my convictions. After some careful consideration and hours of contemplating, I can now say that my expert opinion regarding this heuristic is: “It depends”. (Ha! Surprising answer for a consultant, right?)

TL;DR: There’s a lot of articles and blog posts on preventing or shortening cold-starts for AWS Lambda instances. I learned that AWS Lambda forces cold-starts to happen nevertheless by terminating active, running instances every two hours.

AWS Lambda is an event-driven, serverless computing platform delivered by Amazon. It runs code in response to events and manages all the computing resources required by that code. In their responsibility for managing computing resources, it is known that AWS terminates idling Lambda instances. I discovered that AWS also terminates active, running instances, and quite predictably so.

Recently on Twitter Chris Richardson asked if anyone has created a consistent and comprehensive glossary for EventStorming core concepts.

I replied saying that #EventStorming is fuzzy by design. There are standard core concepts, and depending on the context, we use different words for the post-its. Because with that fuzziness, you get more insights. I call it just enough structure to let transactional conversations flow and create a shared mindset and tons of new insight—a shared pool of understanding. However thinking back at past workshops, and from skimming the EventStorming book checking out the core concepts, Chris has a point, we lack an excellent consistent glossary of the core concept, also specific per type. This post describes my take on EventStorming core concepts written down in a consistent and comprehensive glossary. Just be sure to try and avoid jargon as much as possible, as it sets up the unnecessary insider-outsider distinction.

I have moved the content of this blog to the DDD-crew GitHub page, were it will be updated by the community.

https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet

Nowadays, Cypress is rapidly becoming the standard for UI test automation. With cross-browser support being available as per early June 2020, we at Xebia see the traction growing and growing. We’ve recently contributed to this growth by open sourcing a plugin that ensures that Cypress tests can deal with file download dialogs from the browser. In this blog, we explain the background and how we approached it.