Mob programming is a great BDD implementation

“All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer”  Woody Zuill

A few weeks ago, a co-worker proposed to experiment mob programming. I expected to enjoy this practice, I was actually delighted.


We are a pizza team (3 devs, 1 BA, 1 QA) in an agile context, not working perfectly but striving to improve. We have an automatic delivery process and a code coverage around 80%. Collaboration is quite good and we’re trying to follow some BDD practices.

We decided to give mob programming a try to develop a new feature. Our job is to develop a library to communicate with some hardware whose data model is changing. Our target is to be compatible with both versions of the model with no impact on end users. pizza-10


We did it in a meeting room, not in an open space. We had a computer, a big screen to display the code, two keyboards and two mouses allowing two developers to code without having to switch.
We also had a smaller screen to display useful technical or business data, and a big whiteboard.


The collective intelligence emerged. Questions and answers kept on coming. We drew the big picture, and saw which implementation choices we had. It was crucial to discuss with the domain experts the why of the model evolution, it allowed us to understand the business impact expected for this feature.

The test suite showed again how useful it is, we saw the impact of our choices within a few seconds. It was interesting for the BA because he had never seen these red/green lights in action. We refined our Ubiquitous Language, and it allowed our domain experts to understand our implementation, just looking at the code with us.

It was exhausting, much more than pair programming. In a mob, there is always someone or something to bring your focus back. It’s really productive, but it’s unsustainable if you don’t manage regular breaks.

Business experts were really involved, they were focused to understand and challenge our implementation choices. We challenged them back on some business terms and use cases.
They were reassured because they see how we technically deal with the problem.

We went out of our comfort zone together.comfortzone


BDD is about communication, and communication is about (professional) empathy for your co workers. You want to understand their perspective to (well) solve the (right) problem together. For this reason, mob programming is the best BDD implementation I know.

No framework, no process, no bullshit. Just bring the 3 Amigos (or more!) in one room and focus all together on one specific issue to solve.

Even if it was meant to be a hard problem to solve, we needed only a few days to find a satisfying implementation. Put enough knowledgeable people in the same room, let them produce code and you will obtain a robust and well understood solution quickly.

Think about it, how many useless meeting do you usually attend to grab enough knowledge to implement something? And what do you produce with this knowledge? Word specifications and/or powerpoint explaining the workflow? How effective is this knowledge transfer? Remember the first principle of the manifesto?

“Individuals and interaction over process and tools. ”


Do we need some meetings first

Absolutely, don’t do it if the topic is absolutely unknown. You need to have enough knowledge in the room to explain the problem and think about a few solutions.
A method like event storming would be more useful to explore the problem. You can’t just jump into the code, you have to explore the problem first.

But don’t look for the perfect solution during this exploration phase. I would even argue that you can’t find the best solution during this phase. The goal is to grab enough knowledge to understand the problem, and think about options.


It was definitely a really good experience, and I’m looking forward to do it again. There’s still lots of unchallenged habits in our traditional ways to develop software.

It makes sense to get people who know what to do and people who know how to do, in the same room, and let them build something all together. No Word/Excel/PowerPoint document will create value for your Company. Why not just remove them from your process?

Invest on methods such as Living Documentation instead, to generate documentation directly from your code. Get a documentation which is a true representation of what the software is, intrinsically.

Mob programming is definitely a new good habit I’ll try to share with other passionate co-workers.


Thanks to my team for the experiment, and to my reviewers:
Charles Bouttaz
Jean Helou
Nadège Rouelle
Maxime Sanglan
Woody Zuill


The DDD paradox

Or why DDD is my silver bullet.

Yep, I said the word “Silver Bullet”. All the trolls are now out of their cave ready to hurt me with their clubs. But before hitting me, have a cup of coffee, relax and read on. troll

Where is the paradox?

In every book and every conference about DDD, I hear “DDD is not a silver bullet”. I might be the only one to think the opposite. Thus I probably miss something.

Still, since the very start of my quest to learn about DDD, I use it on every project. Even on easy cases where a CRUD implementation is good enough.

Because to understand my domain and decide if CRUD, is good enough, I interview domain experts.

I may do one or two event storming sessions when possible.  I try to understand the subdomains and see how they are aligned with my bounded context. I crunch knowledge to identify the core domain. This is where strategic patterns from DDD are essential to help me understand the context, in order to decide if it’s appropriate to apply DDD.


You need it when you don’t need it

You see the paradox ? I need DDD strategic patterns to understand a domain deeply enough, to decide whether DDD tactical pattern are relevant, if any. Said another way: strategic patterns are useful to understand any domain, whereas tactical patterns may not be relevant to your context.

CQRS is definitely not a silver bullet, neither are Event Sourcing, Repositories, Entities or Value Object. But DDD in its strategic aspects (domain analysis, bounded context, etc) is pretty much useful all the time.
1-oz-silver-bulletBut sometimes you can’t use it

Perhaps there’s a limit to that, as brilliantly explained by Liz Keogh  at DDD Europe 2016. She did an amazing talk about the Cynefin framework.  When you are in the chaotic area of the framework, it may not even be possible to analyze the business with strategic patterns or any other tools, because any analysis is not even possible. You’re left to act first, and then sense and respond.

But as a consultant, I was never called (yet) to help in such a chaotic environment, or I never recognized it. I’m Usually called to work on legacy systems built with too much technical focus and little analysis of the domains, all this in a complex business domain. And of course it’s not documented and should evolve quickly. Each time DDD Strategic patterns help me to do better diagnostics, faster.


DDD should be verywhere?

Even on the implementation side of a project, there is a lot from DDD that is always usefull. It’s not always about CRUD or CQRS and Event Sourcing. But it’s always about naming the methods, classes, interfaces and modules according to the domain language, the Ubiquitous Language. This is DDD.

If I encourage collaboration between technical and domain experts and work iteratively to refine a conceptual model, I can claim I’m doing DDD.

If thanks to this close collaboration we can find out early that the software we want to build is not critical for the business, I can still say I’m doing DDD. It could save money for the company, for example by chosing a generic off-the-shelf solution, or by deciding to build a quick CRUD solution.  minus

Eric’s plan to conquer the world

This is the DDD paradox, DDD is an approach that even helps you determine when you don’t need it, which makes it pretty much universal. A universal approach seems like a silver bullet to me.
Well played Eric, I start to understand your schemes.



Thank you Cyrille Martraire  for your awesome review.



Remote working as a norm

Remote working as a norm

A few weeks ago, I was around the coffee machine at work, looking through the window the usual traffic jam of downtown  Lyon in the morning.  I was asking myself do people really do this every fucking morning? I mean, I understand we need to go to work every morning, but how many people stuck in the traffic jam every morning have really no other choice?

And by choice I don’t necessarily assert everybody should use a bicycle. What about a scooter? What about public transport?

And what if you just don’t need any commute at all because you can work from home? What would be the global impact if remote working was actually a norm, and not an exception?



This is my personal experience, feel free to challenge me at any point. For a little context, I’m a software developer with 7 years of experience. I had worked remotely during 2 years (2013-2015).

This blog post happens because I was astonished with feedback about this simple tweet. So I believe it deserves a little more explanation than 140 characters.


“What do you mean by remote working?”

I mean, normally not working in your company’s building.

In my personal experience, we worked at home but met together for a full day at least once a week. Also if some of us met a pretty hard issue, we worked together for a full day, either just on hangout, or physically in the same office.

I hope you notice ”not working in your company’s building”, working at home is certainly not an obligation. There are plenty of great co-working spaces out there.

Also we know some great companies like Github (ok it might not be great anymore) who were able to run distributed teams across different countries. A common mistake about remote working is: we assume you won’t be able to communicate with your co-workers.

Communication does not necessarily require two people to be physically in the same room. It’s a matter of tools and culture.

Even if I agree that remote communication may be harder than physical synchronous communication, I believe it’s a question of practice.

Good code requires good practices, the same is true for communication. Distance forces your team to improve its communication skills, to be more efficient.

Now let’s imagine the different impacts if globally, we all try to work remotely (I know you already want to scream: “But every jobs do not fit for remote working!” don’t worry, we’ll speak about that in the limits section)

remoteEnvironmental impact

First of all, imagine the impact on traffic if most people work from home or in co-working spaces nearby. Less traffic Jam, less fossil energy used. Of course it’s really hard to estimate what the impact would exactly be, but a quick search on google confirms that traffic is responsible for more than 25% of the global atmosphere pollution.

Because cars are mostly used to commute to work, It’s easy to imagine how big the impact would be if we avoid using them. And I haven’t even mentioned car accidents and related tragedies we could avoid as well.

It would definitely be great for our planet if we stop using our cars for unnecessary commute.


Social impact

Some people react to my tweet thinking I’m an introvert. Funnily enough, I think my remote working period was one of the most social I ever had in my professional life. Let me explain why.

When working remotely, when people ask you to come out for a drink or a restaurant after work, you’re pretty happy to go because you are not tired. You are happy to see people and you know you could wake up a little later next morning if you come back home a bit late.

Currently, I work 1 hour from home, I wake up at 7:30am and come back at 7:00pm. I feel pretty tired when I come back, and certainly don’t want to go out. Even when I do, I can’t come back too late or I will be really tired the next day.

Also you know all these places you can never go because they are open when you are at work? Yep, post office, bank etc. Well it’s no longer a problem, you can enjoy going anywhere without the crowd, and without the stress of losing your weekend in endless queues at some administration.

The consequences are: you are less stressed, have more fun and are rarely tired during the day.

Another interesting aspect is that it would also allow to spread population density and revive some rural or semi-rural areas. If we no longer need to commute in the big city where all the offices are, we might have a better population repartition. It would definitely benefit to little local businesses.


Professional impact

Simple personal observation: I’m globally more productive when working remotely by a factor of 1/3. No rocket science here, I use Pomodoro to track my productivity in a day. At work (classic open space) I perform 6 to 7 Pomodoros per day (around 3.5 hours of focus work), unless I’m working in pair or in mob programming.

At home I perform 9 to 10 Pomodoros per day (around 5 hours of focus work). For several reasons I guess. But as I explained, one of the main is that you have to communicate efficiently when working remotely. The rest of the time you can easily focus without being interrupted.

In an open space, communication is often chaotic, unorganized, and inefficient.  People walk around, and in the space of one minute you can hear about a birthday, a joke, and a critical bug in production.

Being less tired is probably very important as well, I have more energy which could explain my increased productivity.

Another great point, like explain here  is that you are judged with the work you actually do, not by the work you appear to do.
We all know workalcoolhics working very long hours in a very inefficient way and still being often congrats by the management.
In remote, nobody in your team is here to see “how hard” you work. Your only value is the quality and relevance of the code you produce. Maybe a “remote management” would actually lead to better result, at least in the IT industry for this exact reason.


Here we are, I hear you thinking: “But how can a school teacher or a physician work remotely?”

Yes, I agree, not all jobs  are a good fit for remote working. Jobs around software (building or using it) are the most suitable for this model I guess. But remember software is eating the world, right? So we could probably find a lot of jobs that actually fit this model.

Even for those who basically don’t fit, we could imagine different models. I agree, some jobs cannot be done remotely, but remember traffic generates 25% of atmosphere pollution. Even if we could find remote alternatives for 10% of all the existing jobs, it would definitely have a visible effect.


Let’s recap

If we would consider remote working as a norm, we could look how any job could be performed remotely. I understand it’s not possible for all the jobs, but I’m also sure that our everyday commute to our company’s offices is in part due to unchallenged and useless habits.

If we consider remote alternatives when possible, my feeling is that we could have less pollution,  more happy people  and more productive companies.

What’s your feeling?


Great thanks to Haikel GuemarLaurent Caron and  Nieve for the review.