Mob Programming Surprised Me

Рет қаралды 16,250

Жыл бұрын

Mob Programming, also known as Ensemble programming, is an unusual approach to software development. Is it really as crazy as it sounds, or does it really improve the quality and efficiency of the work and help teams to learn more effectively, as teams that practice it claim? So what is mob programming, is this a kind of super-pair-programming or something else, and what is its impact on software development for teams that work this way?
In this episode, Dave Farley, author of “Continuous Delivery”, “CD Pipelines” and “Modern Software Engineering” describes how mob programming works, and what impact it has on the teams that practice it. Dave describes his personal experience of working as part of a mob for a day and how his opinion of mob programming was changed.
-----------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
-------------------------------------------------------------------------------------
📧 Join the CD Mail List here ➡️ www.subscribepage.com/cd-mail...
-------------------------------------------------------------------------------------
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-------------------------------------------------------------------------------------
🔗 LINKS:
“Mob Programming - A Whole Team Approach”, Woody Zuill ➡️ • Mob Programming - A w...
“Mob Programming Defined” ➡️ www.agilealliance.org/glossar...
“Mob Programming”, Woody Zuill ➡️ mobprogramming.org/
“Remote Mob Programming” ➡️ www.remotemobprogramming.org
“Mob Programming - From Avant-Garde Experimentation to Established Practice”: ➡️ danielstahl.co/wp-content/upl...
"The Mob Mentality Podcast": ➡️ lnkd.in/egT9aTCm ➡️ lnkd.in/eiJuvVKS
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Sleuth is the #1 most accurate and actionable DORA metrics tracker for improving engineering efficiency. Sleuth models your entire development cycle by integrating with the tools you already invest in. You get a full and accurate view of your deployments, see where true bottlenecks lie, and keep your team’s unique processes and workflows. With accurate data, Sleuth surfaces insights that your engineers can act on to improve - with real impact. ➡️ www.sleuth.io/
Roost, An Ephemeral DevOps Platform, automates your DevOps pipeline. It creates ephemeral DevOps environments on-demand or based on pull requests. Roost reduces DevOps complexities and shortens release cycles with fewer engineers. ➡️ bit.ly/CD2Roost
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/TricentisCD
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com

Пікірлер: 122

@ContinuousDelivery Жыл бұрын

Want to try Pair Programming? Get my FREE guide on "Pairing Patterns" to understand the benefits and learn about different pairing options, with my tips on how to introduce pairing. Sign up here: www.subscribepage.com/cd-pair-guide

@thought-provoker Жыл бұрын

Probably the highest performing team I had ever worked with was a Mob Programming team. Literally, we were doing in a week what other teams were doing in a year. We ran out of backlog so quickly that management started to wonder why we weren't working ... Ever since that time, I'm sold on Mob Programming.

@HedleyLuna Жыл бұрын

I tried to run this in one of my teams with mixed results. Most of the time, the team had endless discussions about every detail. Not only this, but the team's energy decreased after some weeks, given the extremely high level of "collaboration." Other times, it worked wonderfully. So, Mob *can* be a good idea, but, as always, it's highly dependent on your team's composition and energy.

@jimbrown6422 Жыл бұрын

I think the idea of Mob programming is a much better version of the development process we used in the 70's and 80's at Bell Labs. But even then, we did see the advantages of the Mob. We we required to have all designs reviewed and approved by the entire team before we wrote a line of code. The advantage then was that each developer was mentored by all the other team members. We all knew the system and identified design weaknesses before code was written. In the Mob model, you do that in real time...especially the debates over architectural issues. I am intrigued by this idea. I can see the value. But there are both limits to size and individuals. Some individuals will simply not work well with others by impressing their experience or skills on the conversation. But there is one huge advantage to this model that current processes have completely neglected. That is, mentoring less experienced developers. Its a great way to share both the knowledge and reasoning quickly. I think this is where the efficiencies are gained in the team.

@techsuvara Жыл бұрын

The older I get as an architect and software engineer, the more I enjoy the entire process and coding itself. Although I also spend a lot of time doing video/photo work, I still love software engineering and the process of development. It's wonderful to see new paradigms grow! Thanks for sharing.

@brownhorsesoftware3605 Жыл бұрын

I am all for collaborations of any size. Serial collaboration across time zones can also be highly productive. Mob programming makes lots of sense because it's just like the way they write comedy for TV. What does writing comedy and software have in common? The better and more immediate the feedback is, the better and quicker it's written.

Жыл бұрын

Thank you Dave, never had heard of mobbing before but when you explained the mechanics it makes a lot of sense. I have worked in small groups where everyone has different skills and collaborating felt a lot like mobbing.

@ralftaraschewski6094 Жыл бұрын

Thank you. Now I know we did that already and why it was so much fun. I totally agreed that the speed is impressive. I think the reason is that 5 people have more ideas than 1 or 2. The chance to find the best is much higher and the risk to forget something is much smaller I will try it more often with my team.👍

@jalvrus Жыл бұрын

If I were starting a team these days, mob programming would be my go-to. The few times that I've been able to collaborate directly with others on either design or code were the most fun and most productive times in my career.

@blaiseutube Жыл бұрын

I've been part of an open source weekly mob team for the past year and a half. It's wonderful.

@nakaimcaddis5531 Жыл бұрын

Where do you work? Sadly, not a lot of companies put "mob programming" in their job listings.

@blaiseutube Жыл бұрын

@@nakaimcaddis5531 correct, l did it at an open source project, it's rare to find this in enterprise computing.

@arieheinrich3457 Жыл бұрын

You also have to remember Dave, that the team already knew your friend Dave from previous engagement so there is an element of trust that then was on you as well, as you were his friend and potentially they also knew who you were. Trust is a "MUST have" to reach these levels when complete strangers come in to a team like that. It requires a good culture to begin with.

@ContinuousDelivery Жыл бұрын

Sure, but the level of trust needed to allow me, or any complete stranger, to contribute to making changes alongside, and in full view of, everyone else and allowing me access to the code on my own is very, very different. They could always simply have ignored all my advice on the day, if I had been suggesting stupid, or dangerous things.

@andrealaforgia Жыл бұрын

New hires are complete strangers joining our teams all the time. We must have a process in place that allows them to become productive as soon as possible. Mob programming is great at making people feel welcome and productive as of day 1.

@philipoakley5498 8 ай бұрын

Fagan Inspection - Your introductory piece about the misunderstandings and links to pair programming made me immediately think of Fagan Inspection, where roles are cleanly defined to ensure that purpose and communication channels are effective, sort of Conway's Law as a design criteria. Maybe a subject for a future video ;-)

@miklov Жыл бұрын

Fascinating. It does make sense that it would cut out a lot of information overhead, a way to manifest N heads are better than 1. I have limited experience working with others but I hope that at some point that will change because it kinda sucks working alone on things ^^

@rentefald Жыл бұрын

You shouldn't be alone when in a team. If that's the case, then the team is malfunctioning and needs fixing before any code is written.

@miklov Жыл бұрын

@@rentefald True. A team would be nice =)

@Immudzen Жыл бұрын

We have been doing some group coding at work recently using the vscode live share feature. Sometimes it is one person doing the coding while the others are giving input on how to do something but others times we split up to tackle a problem together. For instance if someone is working on a feature and we realize a new simple function is needed something else that would make it easier to implement it then someone will split off to quickly code up and test that function. Especially when dealing with more complicated math problems this has really helped.

@yapdog Жыл бұрын

Damn, here we go again. Never heard of mob programming before this video, but that actually sounds like one of the core models of my platform. There's nothing new under the sun. Apparently. Thanx again, Dave!

@esra_erimez Жыл бұрын

This puts "The Mythical Man-Month" in a new light

@ferrisoxide Жыл бұрын

Aye, it could break Brooks' rule that adding people to a project already running late makes it run later. It'd be interesting to see some real studies on this.

@blaiseutube Жыл бұрын

It's not about taking less time to complete, it's about improving the shared understanding earlier in the process. It's precisely the remedy to the man-month problem because Brooks was dealing with contributors acting independently.

@errrzarrr Жыл бұрын

Nope

@gentlemanbirdlake Жыл бұрын

It would appear that the eventual cd singularity is mob tdd with feature version switches in the live instance. or is that taking it too far?

@NickSteffen Жыл бұрын

You have to add in that instead of a one team mob you have the whole company mobbing together😅

@DavidRodenas Жыл бұрын

We have been doing Mob Programming for almost a year, and we are more several times more effective together than each one alone.

@DavidRodenas Жыл бұрын

Although... we do something different: we use several keyboards at the same time. We share the editor session, and we work together in the same code at different places at the same time.

@DavidRodenas Жыл бұрын

And same place is same code.... and same TDD tests output!!

@DavidRodenas Жыл бұрын

And the collaboration that you describe often happens. It is great having everyone at the same time taking decisions that affect everyone in the project. That is a great relief, and everyone really contributes. Although, as you say, it might not work in all groups, sometimes there are some people who are more eager to impose than trying to understand others. Even when the do not understand in what they are working, and instead of asking, forces anyone else to make dumb decisions.

@nakaimcaddis5531 Жыл бұрын

Where do you work? That sounds neat.

@DavidRodenas Жыл бұрын

@@nakaimcaddis5531 Well, we have crafted ourselves. The overall company has a different philosophy, yet, they allow developers to take bold decisions. But I do not know why, only my team is working like this. Other teams are so focused on delivering fast, that they fail to see that there are other ways of working more effectively.

@PeterKretzman Жыл бұрын

This video is rather standard for mob advocacy. It presents a good depiction of the nuts and bolts of the process, but falls short of much discussion of the possible downsides, other than to dismiss them as unfounded because Dave had a good experience on this one day. Simply stating, towards the end, that “I’m pretty sure that we can make a decent case for [mobbing] improving efficiency” isn’t much of an argument. It’s actually not about whether mobbing is effective or “better”, because it likely is, in some situations. The question that everyone in business typically asks, and that mobbers tend to deprecate, is whether it’s *enough* better to justify the obviously high investment, along with the abandonment of just about all work done in parallel.

@andrealaforgia Жыл бұрын

>The question that everyone in business typically asks, and that mobbers tend to deprecate, is whether it’s enough better to justify the obviously high investment, along with the abandonment of just about all work done in parallel. Business folks often wonder that indeed. I guess these problems arise when two very different areas intersect: technical practices and people management. My answer to that is that it would be easier to understand if "everyone in business" stopped thinking of humans as machines. Making humans work in isolation produces a worse result than having them work as a group. We've known that since the dawn of time. Humans are social animals who achieve exceptional results by collaborating (whether it's chasing a mammoth or coding a new feature). Besides, there is no point in creating teams only to make team members work in silos. What's the point of making me build a spaghetti and marshmallow tower with my colleagues if then you want me to play in my little corner, with my headset on? In no other field, we'll be able to find teams that don't collaborate synchronously to solve a current problem (football teams, military platoons, surgical equipes). The business folks should therefore stop equating mobbing/pairing with typing. Working together means thinking more clearly, sharing knowledge, achieving consensus, creating better quality, getting higher job satisfaction, avoiding wasteful activities of synchronization and rework (which often happens with post-development code reviews) and ultimately saving time.

@victortodoran1828 2 ай бұрын

Nice video, I see that it is a year old, has the view of the presenter changed over this year? Are there more recent videos on this topic from the presenter?

@duncanbates5361 Жыл бұрын

It's just crazy how it is possible to read the T-shirt.

@Yulrag Жыл бұрын

Yeah, figuring out on your own how to proceed with the code sometimes can take days in some complex areas where trade-offs are unavoidable and no obvious good solution is available. Having multiple experienced people together figuring it out would speed up the decision on how to proceed. It sounds more like a brainstorm coding session, than just a mob programming.

@NickSteffen Жыл бұрын

With more people involved you have a greater chance of someone having experience in any particular area expertise required and instead of having to Google or ask around they are right there to advise. Additionally, people tend to be less productive as time goes on. By switching people out everyone is kept fresh. People who aren’t actively writing code also have the luxury of thinking further ahead so instead of having to pause and think about what to do next you can keep going.

@Quenjii Жыл бұрын

is this CD's first attempt at clickbait?

@AldoInza Жыл бұрын

Gotta pay the bills somehow

@joaovitorgutkoskipaes1850 Жыл бұрын

If It goes on like this, my click will be lost. Unfortunately, either you dance to your own rythm, or dance the algorythm

@DaverSomethingSomething Жыл бұрын

Haha are you serious? It’s always been clickbaity lol. I’ve just enjoyed the idea of clicking anyway and instead getting something worthwhile. It’s a style, it’s fine, and the content is great.

@nedames3328 Жыл бұрын

No.

@BarriosGroupie Жыл бұрын

I suspect mob programming is a fall-out from university courses, where the students typically work in groups of at least three for a programming project, and take it in turns to take over the project with everyone else watching. This is what I used to do decades ago with my lab partners on electrical/electronic engineering lab course work: we'd take it in turns building the experiment, doing measurements, checking one another etc. Upon me moving to large and medium sized companies, the above went out the window where the project manager was the one integrating the various parts, making sure we all did our bit as required in the spec for our work: fantastic for people who just want to coast through their job without the hassle of interacting with their colleagues too much. But then I moved to a tiny LTD bespoke company composed of just five of us where there was one heck of an overlap between the parts we did and everyone giving useful suggestions, raising our standards and flexibility on how we did things: I learned a huge amount compared to my previous companies, including running a small company. But this was at the expense of our time and energy with the company getting more out of us than we were being paid for. Also, you need above average social skills than is usually required for an engineer, so that arguments and grievances could break out between people feeling they're being dominated by other colleagues, unaware of their greater social responsibilities to the group and how intercommunication is incredibly important. So mob programming can be great, providing the correct people on the team are selected and they're financially compensated.

@enolive123 11 ай бұрын

I successfully both facilitated and took part of mob programming sessions that ran for at least a week with 10-15 people (where we in fact accomplished work that was estimated for at least a couple of months). I even experienced one-day events with 20 people that worked really well. There are even people advocating for a fish bowl style mob programming, where only 4-6 people actually participate but everyone can step in at any time which I find very interesting. But I believe those sizes is not sustainable in the long run, except for special events. My gut feeling tells me that a successful mob programming team in the long run consists of 3-6 people.

@AftercastGames Жыл бұрын

Three words: no merge conflicts.

@HansLemurson Жыл бұрын

What if we try just directly linking people's brains together to create a larger hive-mind?

@Jedimaster36091 Жыл бұрын

Is there any data on the cost of doing mob programming? Given a team of 5, is the team delivering at least 5 MD of work in a single day?

@ContinuousDelivery Жыл бұрын

I haven't seen any studies. My experience, as reported here, is that it was more productive than I expected. The team I joined for the day, originally intended to try mobbing for a single sprint for fun, and were still doing it because they were more productive, over 6 months later. This matches experience reports from other teams, but all of this is just based on personal reports rather than more detailed studies.

@Jak132619 Жыл бұрын

I like mob programming when working on parts of a system that change often and are commonly worked in by most of the team, but there are diminishing returns to the number of people you can add to a mob. The problem is the advisor role, unless all your team are quite vocal then inevitable some people will sit quietly and not contribute / pay attention. A lot of the advantages in mob programming can be gained by having multiple pairs working on different problems (rubber ducking doesn't need 5 people), and so I think this does sacrifice some efficiency. Interesting experiment though.

@michaelrstover Жыл бұрын

Yeah, I wouldn't contribute because I just don't feel comfortable with verbal communication. I get flustered. I don't think the same as when alone with my thoughts. And I never know when others are done talking (too many seem like they're never done, but only get interrupted eventually).

@andrealaforgia Жыл бұрын

Every complex collaborative work activity requires a certain level of communication skills. It's just part of the job. If people sit quietly and do not contribute or even pay attention, that's a problem. It's deeper than just what happens in mob sessions. It's a professional ethics problem. As part of the hiring process, it is crucial to explore the communication ability of a candidate and their attitude towards teamwork. I do think that there is an upper limit to the number of people who can work in a mob and, based on my experience, that's 4 or 5. Pair programming is good but only when pairs regularly rotate. Otherwise the problem is that pairs are going to cristallize, with people who either always want to work together or never want to work together.

@michaelrstover Жыл бұрын

@@andrealaforgia well, you would casually throw out a whole category of capable programmers then. I don't think the world is improved by narrowing the types of people we allow to contribute.

@andrealaforgia Жыл бұрын

@@michaelrstover I don't throw out anyone. I try to make processes inclusive for everyone. Being capable is not enough, though. You must also be able to collaborate. Collaboration is a fundamental requirement in software engineering.

@dgsagoskis1851 Жыл бұрын

If honestly, I would never work in pairmob environment. I tried many times. It works to solve one problem, but not on constant basis. Talking (in general) exhausts me. And I like to work on 10 streams in parallel (css, html, cdk, AWS lambda, db all in parallel) Enough about me, I am just sad if we get to the point (pair and mob is growing in popularity) where people will be discriminated for being introverted and lone wolves.

@_TeaMaster Жыл бұрын

Publishing it on April first would have made the video so much better)

@KaiWegner Жыл бұрын

had the same thought

@beyse101 Жыл бұрын

Very interesting. Do you have a guideline how big the mob should be? Shall it be 3 people, 5 people, 10, 20? How big is too big? How small is too small? Thank you for your valuable advice.

@blaiseutube Жыл бұрын

At least 3. Probably less than 10.

@ContinuousDelivery Жыл бұрын

I'd agree with @blaiseutube 2 is a pair, not a mob (still good though) so 3 or more. The team I worked with was usually 6, one person was missing on the day I was there. They said that they were more productive as a mob. I don't know where the upper limit is, but I'd guess 8 or 10 is too many?

@pejko89 Жыл бұрын

Cool t-shirt 👌

@stevecallaghan7523 Жыл бұрын

So how can you put measures in place to avoid a single dominating voice from overtaking the process? And how can you spot people, who are perhaps weak, that are coasting on others coat-tails? For every brilliant team you come across, you will find many more mundane teams - just the law of averages. How do you measure individual progress to assess performance for commendation? There are just too many questions raised here that are nothing to do with coding, and everything to do with team management, so you replace on problem with several more.

@blaiseutube Жыл бұрын

Umm, it's not quite like that.... I can tell you have not tried it.

@stevecallaghan7523 Жыл бұрын

@@blaiseutube that's right, I haven't tried it, which is why I asked the questions, hoping for someone to enlighten me with reasonable answers.

@liquidcode1704 Жыл бұрын

100% of people working in a "mob" are by definition weak and inferior. Period

@nakaimcaddis5531 Жыл бұрын

What is it about mob programming that makes you think those questions would be harder to answer than in a more typical working style?

@stevecallaghan7523 Жыл бұрын

@@nakaimcaddis5531 Because in a more typical process it is the responsibility of the individual to deliver something, ergo the quality and speed of the delivery is directly attributable to them. You know that dominating personalities directly influence the outcome of meetings and decision making, the same will happen with any multi-contributory process including this. It's also true that some people hide behind the group, and others are shy so feel intimidated when contributing - we therefore won't get the best out of the individual in all cases, and that will limit their growth etc. It's interesting my original questions have not received answers, just challenges - has anyone had enough experience of this process to give answers?

@yp5387 Жыл бұрын

I believe, everyone has a different range of golden hours and forcing someone to be driver for 15 minutes outside their productive hours is not a healthy situation.

@avilego4038 Жыл бұрын

I would never work for a company doing mob programming. It doesn't lead to better code, quite the opposite and besides that is very anoying and frustrating

@SarkieU Жыл бұрын

I like to stick with the original (I think..) use of the word Typist, instead of Driver. I feel like the connotation of Driver is even stronger in remote situations, where the Driver is the leader of the meeting, which is ot the case in a mob

@timseguine2 Жыл бұрын

I am not that surprised if it works. It is similar to the way comedy television shows are sometimes written.

@EmilNicolaiePerhinschi Жыл бұрын

ha, I'm doing "mob programming" like every other week, and remote: one drives the keyboard, the others (like 3 or 4) have thoughts :-() I hope it remains something you're allowed to do, and it does not become something you're forced to do ... too intense for me

@andrealaforgia Жыл бұрын

If it's too intense, then you can inspect whether you are working at a sustainable pace. There are ways to perform mobbing effectively (frequent breaks/rotations, hard "let's call it a day" deadline, etc...)

@rentefald Жыл бұрын

I have done mob-programming a couple of times, and sad to say, each time the code ended in a mess. Stupid short cuts, no organizing. If I have done it myself I would have taking my time to think 90% and code 10%. I only believe in mob-programming when developers are young and need to learn coding.

@qj0n Жыл бұрын

I think these shortcuts are a natural effect of a rush, which we naturally feel on meetings with multiple people. When the whole team meets for an hour, they don't want to spend this time going into details as they don't want to waste it. It's good strategy if we do a mob programming for only particular task and later some individual will clean up it. But if all we do is mob programming, it requires a huge shift of thinking

@dlcardozo Жыл бұрын

Try to switch the pilot faster, when you know that you will have a turn in front of the keyboard everyone will pay attention. When people knows that they will not touch the code in that session you will end with what you commented.

@salvatoreshiggerino6810 Жыл бұрын

Did you use TDD?

@andrealaforgia Жыл бұрын

>Stupid short cuts, no organizing. That has nothing to do with mob programming :)

@avilego4038 Жыл бұрын

Couldn't agree more !!

@adrianojordao4634 Жыл бұрын

No doubt 5 + 2 is more then 1, are you saying is more then 7? The refactoring and the new funcionality was work for more then a day for 1 or 7? Did not understand that... Sorry, for the english, tx for the chanel. Always great!

@ContinuousDelivery Жыл бұрын

I am not sure where the line crosses, but I'd guess it is around 4-5 people, so more productive than 7 maybe not, more productive than 5, yes, maybe. Others that have done a lot more Mob programming than me say "more productive than 5 certainly". The team I worked with was a team of 6, there was one person not there on the day I was there. They had started Mob programming for a single sprint, for fun, and had never gone back to what they did before because they were a lot more productive as a mob, and they had data that showed it - I don't have access to that thought so I didn't mention it in the video.

@orange-vlcybpd2 Жыл бұрын

Don't you think emotional intelligence of the participants is a definitive prerequisite for such kind of collaboration?

@andrealaforgia Жыл бұрын

The ability to communicate is a prerequisite for any sort of collaboration, even asynchronous. Mob programming is nothing different than working together. The team must establish a relaxed and psychologically safe atmosphere where everybody is free to think out loud and share.

@ForgottenKnight1 4 ай бұрын

Yes- you need to keep your ego in check and understand that feedback, opinions or other informations are not directed at you (or your opinions) but at the problem at hand.

@therealjordiano Жыл бұрын

For me there is one obvious advantage to this, and one obvious disadvantage. There may be others, but im thinking now that, perhaps some scenarios would benefit a lot from 'the mob' and others would be best with the traditional approach instead. The advantage I see is the supremely effective spreading of knowledge among the mob members, imagine entire groups of people having acquired big chunks of knowledge of the codebase. The disadvantage is, I feel when coding that I need time, and honestly some tranquility, to be able to think through the problem steadily and come up with an accurate solution, especially for more complicated problems, and I don't think its possible to do this deep thinking whilst in a mob.

@andrealaforgia Жыл бұрын

>to be able to think through the problem steadily and come up with an accurate solution, especially for more complicated problems, and I don't think its possible to do this deep thinking whilst in a mob. Yes, it is possible, but it's a skill that needs to be learned and perfected. Problems must be solved collectively, not alone. The solution is always better when multiple brains share ideas/approaches. You can still spend some time in isolation, if you need, but check back with the team frequently. The risk with thinking alone for too long is that we don't find flaws in our reasoning early, and may go off a tangent.

@yuggothfungi Жыл бұрын

I wonder what are your thoughts on trying such thing with students. It seems like a good seminar routine.

@ContinuousDelivery Жыл бұрын

I know a few consultants that use it for teaching. I haven't tried this myself.

@andrealaforgia Жыл бұрын

I can tell you that some coding bootcamps (I've been a mentor in one of them) use pairing and mobbing regularly, rotating the bootcampers. It works really well.

@dinoscheidt Жыл бұрын

Note: I am not subscribing to „And number 3 will surprise you“ kind of buzzfeed titles and youtube channels.

@timgwallis Жыл бұрын

Mobbing is awesome. Role switching is dumb, at least in such a predetermined way.

@guilherme5094 Жыл бұрын

👍

@nikitaproit Жыл бұрын

In my experience, I can say that it is possible to effectively plan the all code for the day. Spending 50 minutes on stand-up in a team of 5 people to speak the code that will be written today gives the same results as in pair (= code review without issues). If difficulties arise, you can use pair programming or mob. But writing all the code together is a waste of time. Typing code is usually not a big deal for middle+ dev.

@andrealaforgia Жыл бұрын

Pairing/mobbing is not typing. It's thinking about problems together.

@nikitaproit Жыл бұрын

@@andrealaforgia To help with inspection, Scrum provides cadence in the form of its five events. And adaptation must be Just In Time with Inspection. So it's too late to think about problems together. 1. The code is most often not the artifact that is transparent to all Scrum team members, only for devs. 2. However, if the code is really transparent(predictable), then you can write it without the help of another devs. So the only reasonable use of pair programming is learning how to write predictable code.

@Thorax232 Жыл бұрын

Otherwise known as a small team in the same physical office. Not an open floor with managers peering through windows. This only works in one very specific environment.

@andrealaforgia Жыл бұрын

Wow... where do you work, in a rat cage? :D Mob programming works in environments that embrace mob programming :)

@Thorax232 Жыл бұрын

@@andrealaforgia Remotely. I can tell you I don't need 3 people chirping in my ear when I'm trying to focus on a real problem.

@andrealaforgia Жыл бұрын

@@Thorax232 Jesus Christ... the way you guys trivialize valuable practices is incredible: "3 people chirping in my ear". It must be such a pleasure working with you.

@Thorax232 Жыл бұрын

@@andrealaforgia It's the opposite. You're clearly here to forward some goofy agenda, you pledge your life to the worship of X corporate practice. Everyone talks about people like you when you leave the room. Nobody wants to argue with people playing a game like you. So they go along, sit around for 6 months to a year and leave for a "better opportunity". You're the problem with this industry.

@MJ-xl5jz Жыл бұрын

I guess it depends on the level of competency among the team members and on their attitude. A clueless team won't advance much and loses time in debate when it should do research. As for attitude, drive-by programmers could turn the program into a mess just as quickly but conveniently only take the blame as part of a group.

@andrealaforgia Жыл бұрын

A clueless team does not achieve any results with any way of working.

@evennot Жыл бұрын

TBH, it sounds like a nightmare. One debugging case can easily take 40 minutes to reproduce with a dozen files opened at the same time. And then the timer runs out? It is an unnecessary stress. Also sometimes I have to use 2 computers at once (not to mention servers). For instance, when the first one is waiting for hours for a specific symbolic breakpoint to activate in a high-load job with an IDE on the verge of crushing. Limiting developer to a single terminal is counter-productive. Also I watch youtube videos in the background, while I do some boring tasks, like localizing a side-effect introduction within hundreds of commits. Or when I look through CPU profiler results for the juiciest and easiest culprit, when I browse through code review waiting for my gut feelings to activate, etc. This half-idling mode is why I pick this job. Also for the comparison to writers' teams, I'd say there's no comparison. Maybe for English-speaking writing it's different, but I chose literary writing as a hobby precisely because it's nothing like coding

@Siderite Жыл бұрын

This sounds like working while being in an eternal meeting. Nope!

@andrealaforgia Жыл бұрын

No, it's working together, it's communicating, it's collaborating. A meeting can be working together, but working together is not necessarily a meeting. A meeting is communicating, but communicating is not necessarily a meeting. A meeting can be collaboration but collaboration is not necessarily a meeting.