Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?
Become a patron for just five dollars a month. You
get access to a private RSS feed where all the
shows have no ads. Twenty dollars a month, we'll get
you that and a special dot NetRocks patron mug. Sign
up now at Patreon dot dot NetRocks dot com.
Speaker 2: Hey, Carl and Richard here with your twenty twenty four
NDC schedule.
Speaker 1: We'll be at as many NDC conferences as possible this year,
and you should consider attending no matter what. The Copenhagen
Developers Festival happens August twenty sixth through the thirtieth. Tickets
at Cphdevfest dot com.
Speaker 2: Ndcporto is happening October fourteenth through the eighteenth. Tickets at
Ndcporto dot com.
Speaker 3: We'll see you there, we hope.
Speaker 1: Hey, guess what, it's dot net rocks number one four
h So it's almost the beginning of World War One.
Speaker 2: That's it. Sure we are, I'm doing this for a while.
Just wait to use you the comment today, friend, you'll
you'll laugh.
Speaker 1: Oh that's gonna be good. Well, anyway, I'm Carl Franklins,
Richard Campbell, and we're going to be talking to Ulrical
Melgren in a few minutes. But first let's do that
thing we love with a doo dooo dudes. Music? Better
know a framework? All right? Man? What do you got? So?
Our friend Simon Kropp sent me this. It's not as repo,
it's Tyler Brinks and the name of it is Sequel
Parser dash CS. It's an extensible sequel lexer and parser
for dot net. Interesting. Yeah, it was ported from a
Rust project. Right, you parsequel statements into an abstract syntax
tree and there you go, and now you can, you know,
querry your way around it. Interesting.
Speaker 3: Cool?
Speaker 2: Why do I want this? What's wrong with t sql?
Speaker 1: Well some of us aren't tseql gods, such as yourself Richard.
But I'm a god of anything good. Well you know
I think you are.
Speaker 2: But okay, just another way to get at the data.
Speaker 1: Yep. I love it. And you know that's it and
if you need it, you need it. That's what I think.
That's fair. I buy that.
Speaker 3: Yeah.
Speaker 1: So who's talking to us today, Richard? Well, you know,
I know.
Speaker 2: We're talking about MOB programming, right yeah, And we've talked
about mob programming before, so I figured I'd go back
and what he's out of coincidence? But by the way,
what he's still doing his thing, he's doing he's still
doing workshops, he's out there. Yeah, by coincidence. The last
time we talked about mob programming was in twenty thirteen
on episode nine to twelve. Oh my gosh, now we
published nineteen twelve today when we're recording this, Yeah, on
August twenty seconds, so literally a thousand episodes ago.
Speaker 1: We did something weird.
Speaker 2: We actually talked to an entire mob, which included Woody
Zoo right about mob programming. And actually we had a
ton of comments on that show, so I figured I'd
drag out a ten year old's comment. I mean, what's
the big deal?
Speaker 1: Really, it's a very American thing, right, It's like, oh,
you like pair programming, how about mob programming? How about it?
The only we know it would be better?
Speaker 2: More So, ten years ago, Richard Garside wrote this comedy.
He says, I'm wondering how far you can scale a mob?
When does it stop making sense to recruit new people
for one mob? And what point you start multi mobs?
Speaker 1: See? See that's exactly my point. More more a mob
not enough for you. More mobs make more mobs. You know.
Speaker 2: I think we're gonna take that. Got to take that
question over to el Rica at some point. So, Richard,
thank you so much for comment. I hope you still
hear this ten years on, or at least you'll get
the email prom and so forth. A copy of music
code BI it is on its way to you. And
if you'd like a copy of music Cobe, I write
a comment on the website at dot at Rocks dot
com or on the facebooks. We publish every show there,
and if you comment there and I read it on
the show, we'll send you copy music Coby Music to.
Speaker 1: Cobe by still going strong after all these years. Yeah,
and still a favorite way for people to get into
the zone when writing code works for me. And you
can follow us on X Twitter because we've been there
for years before it was X. Of course many many
years before it was X. But the cool kids are
hanging out. I'm mastadon, I'm at Carl Franklin at tech
Hub dot social, and I'm.
Speaker 2: Rich Campbell at Masdon dot social.
Speaker 1: So send us a two. That's another way that you
could get a copy of music to code by for sure. Okay,
let me introduce our guest. Ulrika Malmgren has been in
the software industry in some form for twenty years or
so as of this recording. Anyway. She started out as
a software tester, using exploratory testing to study and learn
about software and users. After realizing that quality was more
more than just testing, she worked as an agile coach
to help teams improve their ways of working. But for
the past eight years she's been a c sharp developer,
working mostly with back end applications. The last six of
those years have been using MOB programming as said fourth
in the comment, or software teaming as it's also called
as a way of working. So url COO, welcome to
dot net rocks.
Speaker 4: Thank you, thank you for having me.
Speaker 2: I was really excited to see you had this talk
at NBC Oslo, and I'd meant to do the interview
there in person, but things happen, so now we're doing
a little bit later from there because we haven't talked
about MOB programming in ages, but clearly it's still going
on wood He still doing his thing, like there's plural
size videos on the topic. How do you explain mob programmer.
That's team programming.
Speaker 5: Ah, I would explain it as the entire team is
working together, so we're programming together. I liked how you said,
like para programming on steroids were even more power programming.
Speaker 4: But also.
Speaker 5: Not just the programming part of it, So the entire
team is working together, but maybe also answering emails, preparing
power port presentations, all the other stuff that you do
when you're doing software development.
Speaker 1: I was going to say, the last time we talked
to Witty about this, everybody was in a room and
one person was driving visual studio or whatever the software is,
and everybody else is sort of chiming in. And now,
in the age of zoom and remote, that must be
quite a bit different, isn't it.
Speaker 4: It is, but it works really well, so we do that.
Speaker 5: Actually, my team is fully remote, so I get to
spend a lot of time with my cat, and that's good.
But what we do is we have a computer at
the office, and we're using ANIDSK to remote to that computer,
and we have a slack or a team call or
something ongoing HM, and we talk and we do all
of our communication and programming on that computer. So I
don't have the source code on my laptop. Actually, I
only use my laptop to connect to this computer and
to do personal work, things like things that are just
for me, right, And.
Speaker 2: I find that a fairly common practice putting my run
ass hat on where the sort of data integrity points
of view or keeping all the source code in the
company means you're just logging into a virtual machine or
a remote instance somewhere and that's where all the code lives,
and the home machines don't actually have don't ever run
the code, they just have access to it through a console.
And that solves the problem that you know, you don't
have to synchronize, like you're all working one place and
you still have that MOB program in mindset of there's
one active keyboard on the code.
Speaker 1: How many monitors do you have?
Speaker 4: I have the one is a big one.
Speaker 5: That's the downside of it, because we only have one
monitor on the office, so we that's the one we
have connected to.
Speaker 2: And I certainly remember that from some of the other
conversations we had in this space where often somebody in
the MOB is on another machine and they're searching for
code samples, and other cases of addressing this particular problem
like many in some cases totally short circuit the development process, like, wait,
this has been done. Here's an example, and it's starting
to look like what we're already doing. Like, let's go
dig into this exactly.
Speaker 5: You can while you're troubleshooting. You can have multiple threads
of googling going on at the same time, so you
can be I'll stack over frough a couple of people
trying to find what could be a possible solution for
this at the same time if you want to.
Speaker 1: Yeah, so I knew what he told us about the
metrics being you know, productivity wise being very very good.
Are there any new numbers or any numbers that you
can share with us in terms of, you know, single
developer at a time and a team working versus pair
programming versus mob programming.
Speaker 5: I'm not aware of any, and in our teams we've
only done this.
Speaker 4: We don't have any numbers to compare to.
Speaker 5: Yeah, but I feel that there's so many situations where
we are that this software team and mopgram is just
helping us so much that I would have to say
that the numbers would have to be good towards more programming.
I'm thinking of all the during the summer. Now, because
of vacations, I was sometimes alone at work and I
was sitting there and it took me a while to
figure out why I was doing this stupid mistake, which
would have been something that my team would have pointed
out immediately.
Speaker 4: They would have seen immediately that I was doing something.
Speaker 1: You say, this is an interesting dynamic here. Now, what
if you have I don't know, let's say you have
a team of thirty and ten of those team members
are working on this part of the app, and ten
are working on another part of the app, and ten
and working on any Does everybody work on the same
thing all at the same time, so like there's no
such thing as a merge conflict or how does that work?
Speaker 5: Yeah, I'm not very good at bronchos because I've never
used them.
Speaker 1: Yeah wow, yeah those.
Speaker 5: Sizes though, So we have teams of for now, two
to five people.
Speaker 1: Yeah, yeah, so.
Speaker 4: We don't have that kind of a size of a team.
Speaker 1: And that's a dressing a dressing.
Speaker 2: Their listener Richard Garsides comments like, how big is what
can a mob really be? Five seems like a reasonable
number where everybody can still be engaged.
Speaker 5: Yeah, I would say three is really good, and then yeah,
the engagement thing is a thing because if you were
doing it, So one way of doing more programming is
using a timer and having people rotate at the keyboard.
So you'd say, every ten minutes we change driver, we
changed a person is sitting at the keyboard when is
actually typing the code. But all of the time you
get to have input on what is being done. But
sometimes you want to rotate, and if you are five people,
you get ten minutes at the keyboard and then you
have to wait forty minutes.
Speaker 1: Once an hour y.
Speaker 4: Yeah, and for some people.
Speaker 2: If typing is what you like in programming, right, I mean,
I got to think there's some natural typers and some
natural searchers and some natural reviewers.
Speaker 4: Too, exactly.
Speaker 5: So we have tried those kind of rotation patterns, but
we've also sometimes gone away from them and have had
a more natural kind of cycle of some people like
to type more, some people like to go go think more.
Speaker 4: Yeah.
Speaker 1: So to get back to what I was saying before
though about multiple team sections working on different sections of
the code. What if there's somebody on the team that
you know when you go down a rabbit hole in
a particular thing, that they're not even working on. Do
they contribute as well? Do you have to take time
to explain what the other people have done to those
who haven't done it yet. I mean, there is that
a problem.
Speaker 5: That's actually sort of an excellent point towards my programming
and the fact that when you are in the mob
and you're working on a thing, you get to see
the rabbit holes, so to see, like, Okay, we went
down this path and we found a dead end. This
wasn't actually the way to solve this problem. And you're
learning those things as well, because if you're just doing
like a pull request and you're sort of explaining this
is what I did, you rarely explain the other paths,
the paths that you didn't take.
Speaker 4: The things that were dead ends.
Speaker 5: Sure, you get to learn the thinking that up to
the actual solution, but I.
Speaker 1: Can also see how you know, if you've got parallel
sections of the team working on different aspects of the
application all at the same time, are they three times
as productive as the whole team working on one of
those at a time? Like some people may think.
Speaker 5: That, yeah, I think you want to have very like
your own domain or your own application and not have
to share that with someone else.
Speaker 4: I think that's also a key to getting making it
work all right.
Speaker 1: So breaking down the teams into sections that are working
on a particular thing. We're all working on that thing. Yeah,
that makes sense.
Speaker 2: And the point being that, just like we saw with
pair program, and there's two pairs of eyes on something,
you tend to make fewer mistakes, Like that code tends
to be very check inable and sticks around. There's less
iterating on it. I like the third pair of eyes
because they do the other thing. You know, you definitely
need two pairs of eyes on the code at any
given moment, so that as soon as that third ones introduced,
that's the one that could be searching yeah, you know,
or thinking yeah and pulling new information into the equation,
or reading even just reading the smacks in more detail
and saying do we actually understand this? Right?
Speaker 1: Like? You know, it's kind of like a continuity person
on a movie set, isn't it somebody who's got a
sixty thousand foot view of everything and says, oh know,
in that last shot, the coffee mug was half full.
You got to fill it up again.
Speaker 5: It also sometimes looks a bit back when we were
in the office and doing this. It looked a bit
weird to the others because we were sitting and discussing
a lot, and we were talking and talking, and then
finally we reached consensus about what is it we're actually solving,
how do we want to go about this, what's a
solution we can all stand behind. And then when we
finally reached that consensus, just typing out the code wasn't
really something that took us very long.
Speaker 2: It was the easy part because you had consensus. And
I got to think, if you've got four people agreeing
on a path and they're really agreeing, like there's not
a lot of bullying going on, the quality of that's
going to be pretty high.
Speaker 4: Yeah, it is.
Speaker 5: And also you get but you have to sort of
learn to sort of this is something I really want
to stand up for, right, I'm just I'm not we're
doing tabs and not spaces. I'm going to die on
that hill now, that kind of thing. And then you
need to figure out what are the things that I'm
willing to let go of and that I'm willing to
slip because I think you can't win every bottle. You
can't have four people having absolute consensus and everything. So
you have to be a bit of a You can't
be too opinionated about everything.
Speaker 2: You can't fight to the death on everything, and nobody's
going to want to work with you eventually. Like there's
just there's got to be some This is not that
important to me, it seems more important to you. Let's
try it, because let's face it, none of this is permanent.
You could go back and revise. Yeah, better to just
get to a path where it's like, I don't see
a problem with that. I don't know that I do
it that way, but I don't see a problem. Let's
go and see what we get. Yeah, yeah, I think
that's That's the compelling part of this is that the
biggest thing you get away from with pair programming, I
noticed is the those death sparals just trapped in. I
can't get this out the door. I'm just smashing my
head on the keyboard, and another pair of eyes and
ultimately another pair of hands just breaks that up. And
you're always rubber ducking.
Speaker 5: Yeah exactly. And also you're learning like IF when you're IF.
I'm not very good at CSS, for example, but my
colleagues are better than me, so if I were to
solve this future of my own, my CSS that I
would produce would be at a certain level, which is
not very good. But when we're doing this together, we
always get like the best person's level of knowledge, right,
which is also really interesting and I'm learning at the
same time.
Speaker 2: Do you switch keyboards at that point? Like does the
CSS when you hit to the point where it's like,
well we need little CSS here, It's like, all right,
already take that.
Speaker 1: Yeah.
Speaker 5: Maybe the other way around though, maybe I'll take that
because I'm not so good a right, so you can
be the one.
Speaker 2: To turn yeah and let them coach you through exactly
better see sess yeah, and sharing that knowledge.
Speaker 5: I need to get this from my fingers, to get
the mechanics of it.
Speaker 1: And that's an.
Speaker 2: Interesting angle on this, and it also speaks to I
don't want three of the same person on here on
this project. I want an array of skills.
Speaker 1: I'm trying to think of the pushback, right, If you
have a team of five and you go to your
manager and say, hey, instead of everybody working on stuff
and branching and merging and all that stuff, why don't
we work together? You know, the pushback might be is
I think, well, you have to prove that the productivity
exceeds what you can do individually and the quality. Productivity
and quality they go hand in hand.
Speaker 5: Yeah, And people always say that, and it's really interesting
because has this sort of working individually, has that really
proven itself to be good productivity and good quality?
Speaker 1: M Right?
Speaker 5: Like did we always we were doing software perfectly on time,
bug free, and then some people came along and say
can we work together? And everything went downhills from there.
Speaker 2: Just do more unit tests. But I mean, I think
I want to play with the math on it. So
if we've got four people in a four week sprint,
each takes a task, all right, in the end of
four weeks, you're supposed to deliver four tasks. Now flip
that on his head, and four people work on each
task a week each, all four of them work on
it once. Are you going to get a better result?
Can they deliver those four features one a week collaboratively?
And then I mean, I think it's hard to deny
that you'll get better quality code for having more eyes
on it.
Speaker 1: That's always true, definitely.
Speaker 2: So the quality question is not there the productivity question.
The question is can you get those four features built
that sprint. Like that would be my argument to the
team lead. It's like, hey, our goals deliver these four
things in the sprint. How we do it?
Speaker 1: Don't ask? You know, you can't. You don't have the
benefit of parallel universes. You can't say all right, it'll
do bose ways and see what happens at the end.
Speaker 5: Remember that there's so much more to program to software
development and just the programming part. There's like reading the code.
There's understanding the code, there's understanding why are we doing
this in the first place. There's so many other things
that you're doing. And I think that if you've been
a part of all of the code production up until now,
you're rarely going to be in a position where you're
sitting there and you're not understanding what a certain post
of code is doing because you were there when it
was created. So the part when it is okay, I'm
reading code is taking me a long time to understand
what previous the previous programmer was doing. That part is
gone because you were there for that part.
Speaker 1: Yeah, well, you have the potential for new kinds of nastiness,
don't you like when people don't agree, and they're resistant
to doing it the right way. Has it ever come
to fist the cuffs?
Speaker 5: I think it's even more passive aggressiveness in all the
sines where you're sort of like, oh, I'm going to
change this now, that's my turn to where on this
future I'm going to change it to what I think
is better.
Speaker 2: Edit the code right in front of them. Yeah it's
not pretty.
Speaker 1: Well, Dave did this and introduced a bug because he
wasn't smart enough to think that this and that. So
I'll just fix it right now.
Speaker 5: But also, my most the argument that I like the
most about when you talk about productivity is the one
thing that you hear in every retrospective is we have
to be better at knowledge sharing.
Speaker 4: That's always the thing that comes up.
Speaker 1: And then you share all the time.
Speaker 5: Yeah, and then you have people say like, okay, so
we should have knowledge sharing sessions and then that doesn't happen,
or we should we should be better at talking to
each other, and then that doesn't happen. But we don't
have to solve that problem because we're organically knowledge sharing
all the time. Yeah, we don't have to think about
is this an important thing that we need to tell
someone else about.
Speaker 1: Also really good if one person leaves the team.
Speaker 4: Yeah, yeah, that's brilliant.
Speaker 2: You've always got more pairs of eyes on the code.
You've got them routinely teaching each other. You're not doing
a separate teaching exercise, right, Like the fact that the
skilled CSS person who's in the MOB walked you through
writing better CSS, as opposed to doing like a luncheon
learn on CSS, or just simply getting all the CSS
work from the whole team all the time so that
that person gets better and better but never really teaches
anyone else. Like, there's a whole bunch of things solved
at the same time with this approach, and only a
small part of it is writing the code exactly.
Speaker 1: I think she use a different term than in the MOB.
Speaker 4: That's what I want.
Speaker 5: I want to flip this conversation around, like ken, I
think I when I started to submit talks about this topic,
I wanted to contrast it to the other way of
working the thing that we were doing before. Right, And
it turns out I felt like I needed to find
a name for it because I would have more programming.
That's not a particularly good name, But we talk about
a software team maybe sometimes which is slightly better, but
still a name for something.
Speaker 1: How do you like it?
Speaker 2: Ensemble programming.
Speaker 1: That's very, very very the word area day. Yeah, yeah,
I like it. But yeah, group programming perhaps programming.
Speaker 4: Yeah, but what's the other thing then, what's the thing
that most people are programming? Yeah?
Speaker 5: Yeah, I like that one, and I think I like
even better one that we came up with in the group,
which was individual centered programming or development, because if we
have if in more programming, you take the work and
everyone flocks to the work and does the work. In
the other style, you split the work to the individuals, right, but.
Speaker 2: You still have this great ritual of merging it all together.
But you now are oscillating between working individually and working
in a team where you all have to collaborate on
the integration cycle. Why not just be in the team
all the time?
Speaker 1: About mono programming and polyprogram.
Speaker 4: Multi threaded, single threaded, Yeah.
Speaker 1: Right, remin brain goes, oh, looks like the cat is
taking a walk.
Speaker 2: Yeah, but actually at this point about the oscillation of
switching modes where you go head down on your own
sometimes you know, in a tail spin, to try and
produce your portion of the work. To bring to the team,
and then you work as a team to do the
integration just seems weirder than why if you just work
as a team the whole time.
Speaker 5: Yeah, And there's so much wasted time that is spent
during those synchronizations, like the stand ups, Yeah, what did
you do yesterday?
Speaker 4: What are you going to do today?
Speaker 5: And then you have long stand ups, so then you
spend the retrospectives talking about how should we have better
stand ups?
Speaker 4: So first you waste the time during.
Speaker 1: The stand ups, then you waste more time.
Speaker 5: Than you're wasting the retrospective time talking about how you
can waste the time in a better way.
Speaker 1: Yeah.
Speaker 2: What if everybody knew what everybody was working on because
they all worked on it. Yeah, Yeah, suddenly this weird
idea seems like the normal idea, and what we've been
doing is weird.
Speaker 1: I would think though, that in bigger projects where you
have multiple silos of work, it could pose more of
a problem, don't you What.
Speaker 4: Would be some multiple silos?
Speaker 1: All right, So let's say you're working on a project
that has a solution that has thirty or forty projects,
and you know they hire one person to work on
this one project. Because it uses a particular language or
technology or something, and another person is doing the data
the back end, another person is doing the communications, right,
I mean you've got a team of twenty or thirty people.
That seems a little bit far reaching from me.
Speaker 5: No, yeah, maybe this wouldn't be the best solution for that,
but maybe it would be splitting up that problem.
Speaker 4: Yeah, in a different way.
Speaker 2: Yeah, let's come into this another angle. We kind of
recognize that at any given mob, any given ensemble is
three to five people, right, Yeah, you have a limit,
and so there's a cadence as fast as you can
produce code with that team. Even if that team works
flawlessly together, they're in their their space, they know what
they're doing. They're only going to put out so much
code in so much time, as efficiently as they can be.
And that could be a lot. A lot of projects
could be happily solved that way. But you have a
larger project with way more milestones that need to be done,
and you want to have more people working together. I
don't think you make the individual mob bigger, But now
you get into multiple mobs and you're back to possibly
fighting that synchronization problem wherever. So often those mobs need
to come together to synchronize their code.
Speaker 1: But at least they would be working within their own
domain hopefully and wouldn't be crossing each other, so there'd
be less chances for emerged conflicts and things like that.
I hope, yeah, I mean would you would?
Speaker 2: This is where the architect comes into play and we
build boundaries to say here, you know, maybe negotiate the APIs.
You might even have a mob of mobs here where
one lead from each mob gets together with the other
four mobs and they go through the architecture of how
they're going to build those interfaces.
Speaker 1: Middle management mobs.
Speaker 2: But now you're getting to, like you said, a twenty
to twenty thirty people working on a project that's a
lot of code like but you know, and it's really
a speed thing that they want a certain level of
deliverables in a certain amount of time. So you're going
to introduce complexity. There's no two ways about it. Like
you can't can't get twenty people sitting around one keyboard
and be productive. There's a threshold there.
Speaker 1: But I like the multiple groups or multiple mobs or
multiple ensembles idea because as as these five, four or
five person units, they can be a lot more productive
in their silo than the four or five individually working well.
Speaker 2: And the bigger thing is recognized. Every piece of code
is looked at by multiple peeple, so it tends to
be a higher quality.
Speaker 1: Yeah, produced more rapidly.
Speaker 2: Yeah, you know, because as soon as we getting the
mobs of mobs where now we could be back to well,
why don't you just have individual developers they do the
same consolidation because an individual makes more mistakes and a
group makes for your.
Speaker 1: And some simple rules like those pieces that are shared
among all the projects that somebody has to update, you know,
they have to eraise their hand and tell everybody, hey,
I'm gonna be working on this tonight or tomorrow morning.
Check all your stuff in by five, and then you know,
have it done in a couple hours, and then we
can you know, just prepare. I'm not trying to say,
trying to prevent merch conflicts before they happen. Yeah, yeah,
you would hope, you would.
Speaker 5: Hope if you were to have some sort of synchronization
in between, you can at least send any of the
team members from any of the mobs, because they will
have the same knowledge.
Speaker 1: They should have all the same knowledge.
Speaker 4: About their work at least delegates.
Speaker 2: But just like you have somebody good at CSS, you
might have somebody good at persuading.
Speaker 1: So you want to send it to that mob. Interesting,
it's not just about technology.
Speaker 2: Well, it never is, right, Like, this is all about
how well we work together and how we come to
consensus on things, and how different viewpoints make for a
better answer when done constructively. It can be done toxically,
like what I what I find in you about this
is like, this will certainly hunt down the toxic people
in your group. If you can't make this team programming work,
it's going to show fast.
Speaker 1: Yeah.
Speaker 4: It requires people to be humble and to be curious
about other people.
Speaker 2: Yeah, and to expect understand that they're they're capable, like
they all deliver.
Speaker 4: Yeah, you have to.
Speaker 5: If someone has an adverse solution to yours, you have
to be more curious about why would you that be
a good solution in your opinion? Right, rather than to
bash them and be sure that you win that argument.
Speaker 2: Mm hmmm, well anyway, don't win any argument, right. The
code bench it right, Like, I'm perfectly willing and I've
been in that situation with two really smart people and said,
all right, we're both going to write and we're going
to have a bake off.
Speaker 1: Then right, and you'll see what we That's a fun way.
Speaker 2: Yeah, it's it's an approach. It has its own problems.
Now we talk about metrics. Actually we should break for
a moment for these very important messages, and we're back.
It's done at Rocks. I'm Richard Campell. Let's call Franklin hey,
and talking to our friend Luruka about mob programming for
the first time in a long time. But it feels
more mature now, like I'm maybe it's just as I'm older.
I'm like, duh, yeah, working together better.
Speaker 1: We have more tools now.
Speaker 5: Yeah, to me it feels it feels like the obvious approach.
But it is because I've been doing it for every
day for six years, so sure. To me, it feels
a bit odd to do it any other way, Like
why would you split up the work and split up?
May I have more risk?
Speaker 1: Yeah?
Speaker 2: Yeah, I mean people do pseudo mobbing anyway. The number
of times I've seen an organization where each person has
a piece of code, but they keep checking in with
each other about problems they're having with their code. The
problem is that that's an in interruption driven way to
do it. So that other person was focused and working,
and you pulled them out of that to ask them
a CSS question.
Speaker 1: Idd interruption driven development, that's it.
Speaker 5: I'm terrible at asking for help when I'm working alone.
I will sit and bang my head against the solution.
I'm trying to figure it out. Yeah, maybe this thing.
I'll just try this thing, then I'll ask for help.
Speaker 2: Yeah, totally. And that's what I saw with Paar programmer.
Right away as the other person knows the moment you're
spinning because they're there, they've watched it happen, right, and
it's that coach effect of dude, you're spinning, like it's okay,
let's get you out of the spiral, Like let's rethink the.
Speaker 1: Problem and come at it from a different direction.
Speaker 2: So you no longer have to have the sort of
executive function to go, oh, I'm spinning here, pull yourself
out of it and try and find a way. There's
somebody there, puts the hand on the shoulder.
Speaker 1: It's like, hey, the four most important words a programmer
can memorize and use is well, that didn't work right,
You've got to know when to say that and try
something else. Yeah, wow, wow, indeed this is normal.
Speaker 2: But the remote angles interesting too, because I guess our
text so much better than it was in the past.
Time we were talking about this, like to just sit
in a zoom call or a team's call with all
the faces there, and you know, the code window and
handing off control for typing, and then beside that you've
got another window open because you're doing a little searching
or checking or going over docs and and a steady
stream of conversation about what we're writing. Doesn't even seem
weird now, and a few years ago that wouldn't be
that easy. The pandemic fixed this really pandemic. The pandemic,
I'm not going to go that far, but I'm saying
everybody's ring got better. The etiquette of online communication evolved.
Remember we had the stupid hat period during the pandemic
when everybody turned on a filter so they had the
digital hats on.
Speaker 1: I never did that.
Speaker 2: You missed all that, now, no, you missed out.
Speaker 1: I guess I saw other idiots doing it, but I
did not did not partake of that.
Speaker 2: But it literally was like a rapid incubator evolution to
emerge etiquettes around around online, which I mean it speaks
to there must be a sort of agreed upon etiquette
and mob programming too, like are you big on the
every camera on thing?
Speaker 4: No, we don't actually do that.
Speaker 5: I think one thing that is interesting with the combination
of remoting and more programming is we spend so many
hours a day talking to each other, right that we're
getting to know each other very well. Yeah, And I've
have onboarded people fully remotely and in a way where
you sort of you get to know them personally because
while you're working, you sort of you crack a joke
and then you end up having a mini break talking
about something else.
Speaker 2: I need caffeinated beverage. Now, please do you leave on?
You stay on through lunch already, windy unplug.
Speaker 4: No, we typically.
Speaker 5: Have real lunch breaks and have uh have other breaks
as well, so we try to make sure to have
a break every hour and lunch breaks. And I'm an introvert,
so for me, being remote and getting a lunch by
my own.
Speaker 1: Yeah, is actually important, is really valuable.
Speaker 2: And you need to get off the screen. You need
to get up and move around a bit.
Speaker 1: I got to feed my cat. Yeah, I'm kind of
chuckling because Ulrica's cat has jumped into her lap and
is showing us it's butt.
Speaker 2: Yes, that's brilliant. You're you're keeping it together, just fine
and everything. Everything a great cat again. Another thing that
came out of the online was the pet sessions and
children children wandering in such as I was having a
long talk with a senior executive at Microsoft at one
point and the little girls came piling into the room
and she goes, really sorry. I'm like, it's all good.
Put on a speaker, let's chat. Tell us the story.
They want to tell you stories.
Speaker 1: I want to hear them.
Speaker 2: Let's do it, you know, to spend spend six seven
minutes letting the kids tell about getting home from school
and then they off they go again.
Speaker 1: Way better answer.
Speaker 2: You know, everybody's delighted you talk about, you know, connecting
with folks so exactly.
Speaker 1: Yeah, you know, the social aspect of it. We we
you know, talked about it as being good, but it
really is good. I mean, we can't dismiss that as
a benefit a small benefit. It's a huge benefit. I mean,
you have people that connect with each other are more
happy in general. Well, and if they're more happy, then
they're going to be more productive and gonna want to
solve problems.
Speaker 2: Teams that trust each other are more productive. Yeah, because
it resolves arguments faster. If I trust it, you're smart
and good at what you do. When you disagree with me,
you almost get this, I must have done something wrong,
like what did I miss? Rather than the defensive No,
you know, I know I'm right.
Speaker 4: Yeah.
Speaker 2: That trust makes those things fast.
Speaker 4: Yeah.
Speaker 1: I mean.
Speaker 5: Also, we have uncovered a couple of techniques that we
use when we notice that we have I wouldn't see
a conflict, but maybe different ideas on how to solve
a problem. So one thing that we've done is that
we've actually split the team up in those cases and
we get to go and sit by ourselves, uh and
maybe draw a bit on a on a PowerPoint or
a Mirro or something like that, draw out your solution,
your idea of how we should do this, and then
we come together and we present those those pictures to
each other. Because when you are remoting and you don't
have the whiteboard just next to you, it can be
a good idea to be able to just sit by
yourself and get get to draw a solution, get to
think about the problem on your own, and then then
come back and talk about how should we solve it together.
Speaker 2: It also resists the loudest voice effect to right or
the law. You know, I've often had a talker in
the group where it's like, hey, if I just agree
with you, you stop talking. You know, So to diffuse
that and go okay, everybody, go in your respective corners
and draw out your finish your idea to present back
equalizes the fast talker versus the quieter, more contemplative one.
Like that quiet person if they had thirty minutes to
really round out their idea and then present it with
everybody watching, is going to land better.
Speaker 1: That's a great technique.
Speaker 2: Well an, that's the you know, the amount of moderation
I've done over the years. It's like, how do I
make sure the quieter, thoughtful person gets heard and to
unplug the mob for a bit and let them go
and do that and then come back and everybody gets
a cycle talk through the ideas.
Speaker 1: That's great. You know if in this in another case,
you might have three different ways to achieve the same thing,
and so rather than you know, and it could be
something relatively simple. So rather than have everybody go through
all three of those potential solutions all at once, you
have them split up for say an hour. All Right,
you try it this way, you try it that way,
you try it this way, and then we'll come make off. Yeah,
bake off. Right. You don't want to spend too much
time doing that, but you can where if you're starting
as a group. But if you're not starting as a group,
then you don't have those options. No, you might have it.
Speaker 2: It might have happened privately in each room and only
find out an integration with people spent two weeks on it,
right right, to spend a couple of hours spiking it
and then bring the code. I mean three people go
off to write that code in different ways. One of
them's going to come back O Okay, my idea wasn't
that good when I actually tried to code, like nope,
And then the other two to come back with different approaches,
and it's like, okay, well let's put some insutation around this,
spend it up. What are we looking at? And I'll
bet you none of them are correct, like all of them.
It's like, hey, the way you did that instrumentation was
better than the way I did it. My code may
be fast, but you measure better, Like, let's borrow from
each other and you get a better result. I just
think about how people feel at the end of the
day after an experience like that.
Speaker 4: Yeah, it's much more fun you something together.
Speaker 1: Yeah, I feel like I've been at recess one day
with my friends in grammar school, you know.
Speaker 2: But also heard also took it out for a spin.
Also got affirmed like that's pretty cool, and I never
thought of it that way. We're not doing it that way,
but that was pretty cool. Yeah, that seems very positive.
So many positive elements to this versus now you know,
this oscillation between working independently and trying to integrate.
Speaker 5: Well, so touching on the thing that people are going
to be noticing if they try OUTMA programming, they are
going to be noticing personal conflicts in a way that
you didn't have before because you're used to maybe if
you had a different opinions in a meeting, you would
split up and then go to different desks, right, but
here you're sort of you get stuck in that those
different opinions. You're stuck in that moment of Okay, we're
not agreeing, we have to solve this, and you're going.
Speaker 4: To be stuck in that.
Speaker 1: Right.
Speaker 4: Yeah. Different, So maybe you will notice.
Speaker 5: That your retrospectives might be a bit less about how
do we have a faster stand up and more of okay, so,
how should we handle when we have different opinions?
Speaker 4: What should we do?
Speaker 1: It's not just that, but personality type clashes. Yes, Like
if you're not emotionally intelligent enough to realize that, oh,
that person is the direct opposite of me on the
the Carl Jung's spectrum or the Myers Briggs scale or
whatever you want to use, and you're not smart enough
to know that, all right, well, you know I have
to read past the body language and all of that
other stuff that I'm taking in as information and just
get to what they're saying. Yeah, yeah, that can be tough.
Speaker 5: Yes, I think you will grow as a person in
that sense because you will have to to learn about
other people's personalities. Sure, a bit more and maybe there
to say I feel like comfortable when you're interrupting me,
can I please speak things like that that might come
up to the surface in a way that wouldn't come
up to the surface when you don't have to stick
in the moment.
Speaker 4: Sure.
Speaker 2: Yeah, I keep thinking back to who is the politician said?
Can I finish root?
Speaker 1: There you goanage.
Speaker 2: But you know, I think and you also will have
refereeing type personalities in there. It's like, wait, let's hear
this out. Yeah, I mean it gets challenging when you
get in a situation where we disagree on this. Somebody
wants to spite the code. The other one's like, why
we don't need to do this, Let's get moving on.
It's different people are different pacing. So but I think
he speaks Now I'm thinking in terms of it has
to be an uneed even number, so you don't end
up with a perfect splint on any position.
Speaker 4: Yeah, it does help to have that.
Speaker 2: Yeah, three or five, four would be problematic. Yeah, because
you will have that schism. So yeah, better to have
it and even split, so at least you can get
a sense of, well, the majority disagrees with you, wethough
hopefully they do that kindness. There's got to be a
lot of kindness in this. You're going to be successful.
It speaks to certain set of personalities.
Speaker 1: Yes, indeed, challenges besides the things that we've talked about. Obviously,
I've brought up pushback potential, you know a few things
that you need to be kind of understand before you
pitch this kind of thing. But what are some challenges
or potential pitfalls that people could fall into that we
haven't already talked about.
Speaker 5: I find a typical one that I've heard is when
people go, this work is not suitable for more programming.
Speaker 1: Interesting.
Speaker 5: Yeah, so you're doing a lot of more work and
then things get difficult. Maybe it's a bug that you're
supposed to troubleshoot, and you're a bit stressed out, and
then it gets a it gets difficult, and then your
instinct will be to retract from the difficult moment. And
so people have lots of opinions on this work is
not suitable for mobbing, And I think.
Speaker 2: Is there work that's not suitable for mobbing?
Speaker 5: Possibly if you're doing something very repetitive like putting changing
all the lines in a two hundred and fifty row file,
maybe something like that, that just.
Speaker 2: Means that the rest of the mob is bored. The
typers typing as fast as they can as opposed to
like you, if you've got three people who can and
agree on something that seems very marveable, because otherwise you
would have found out the disagreement after the code was
already written.
Speaker 5: Yeah, but I think situations where you are typically troubleshooting
situations are a bit more difficult.
Speaker 4: Interesting, So what typically ends up? And this is so funny.
Speaker 5: Had a colleague was a senior developer, Like we all
looked up to him, and he had really good solutions
every time. And at one point in time someone asks
him like, okay, so, in your opinion, what makes a
senior developer? And his answer was someone who reads the
error messages that Yeah. I was like, surely that can
That can't be the level that we're holding people out.
But if you look around, people not reading error.
Speaker 4: Messages often a problem. Yeah.
Speaker 5: And so if you did that in a mob situation
where no one actually reads the actual message and everyone
goes like, oh I know what this is yea, and
people have different ideas on what this is is.
Speaker 4: And you're a bit stressed because he's a production error.
Speaker 2: You let somebody, You let the person on the keyboard
run with their immediate age things, but my off the keyboard,
I would want a copy of that error message and
looking it up, and somebody else is searching through log
saying how often it's happened? Like debugging is a group.
Seems really powerful, but it is, but it's hard.
Speaker 4: Oney, hour a bit stressed.
Speaker 1: Yeah, yeah, I can see. Another challenge would be people
who think slower than other people. So take my wife
and I playing a game, for example, she can figure
out we play a logic game, right, and she figures
stuff out way before I do because I'm a programmer, right,
I'm methodical. All right, apply this rule, eliminate these possibilities.
Apply that rule, and she's like, it's there, you idiot.
Speaker 2: You so, But mixing intuitive and logical processing often builds
great results. Yeah, you know, as long as everyone's got
a little patience for each other. I'm coming at this
from an administrator's perspective, where we've been firefighting. It four
of us firefighting an outage, often remote, you know, with
an IRC channel open, which ends up being a record
of us actually diagnosing the problem. And the joke is
every time it's like, hey, it was a six hour outage.
It took us one hour detect it, four hours to
diagnose it, and fifteen minutes to implement the fixing, get
it up and running again, and then another hour to
write it up. But everything is about diagnostics. But having
multiple eyes on logs and searches and so forth made
a huge difference for us. I never thought of it
as mobbing, you know, because we weren't acssarily creating anything.
We were just trying to put out a fire. Yeah,
but you know, the big rule repeating to ourselves is like,
don't make the hole deeper. If you're going to make
a change, you know what change you've made in how
to revert it. So, you know, often we get it
back up, but we've mangled six things trying to get
it back up because we didn't actually fully diagnose the problem.
Speaker 5: And I think that's one of the situations where people
but it's common that people sometimes do I few them
up perming from time to time. They can the teams
can go okay, so this is really important to get right.
Let's do this thing together, or this is an actual outage,
let's do that together. But maybe they're not revert to
it when it comes to normal work.
Speaker 2: Is to do a periodic mob programming with a team,
maybe as a transition from the from traditional styles.
Speaker 5: I think A common one which is pretty good is
onboarding team members. Right, that's a good place to start
if you're in.
Speaker 2: The mob and the mom help them big up, build
out their configuration, and get to check in able code.
Always my threshold for how many days after we hire
someone can they are they capable of checking in code.
It's not about their programming ability, it's about understanding the
infrastructure well enough to have gotten to the point where
their code can be checked in and pulled into this
into the pipeline. Yeah, doing that as a mob would
be more fun, But I'd love this statement you said, like,
this code's too important to do individually, so we'll do
it as a group. It's like, isn't all code that important?
As soon as you can say that, then it's like, oh,
this code is stupid. Let one person work on it.
Speaker 1: Do you transcribe these sessions and refer back to those
transcripts when you have issues?
Speaker 4: No, we haven't done that.
Speaker 5: We can some transcry to summarize it, because it's good
to know why I did with this actually happen mm hmm,
But we haven't had any transcription so far.
Speaker 2: Although let's face it, with a new ll M technology
of the things. Transcription has gotten way easier, transition and summarization. Yeah,
you know, if you're paying for the premium version of
teams that comes in the box now with with copil,
with M three ct I copilot, that every imagine every
you know, six seven hour programming session. At the end
of it, you get an everybody gets an email saying
this is what you did today. I don't know how
high quality that would be, but that's the tools we
have now, Like it's peaks to the whole other elevation. Interesting,
this may actually be getting easier.
Speaker 1: Yeah, all right, So have we left any stone unturned?
Is there anything else that you want to talk about now?
Speaker 5: I think I think with the most important thing for
me is how how I feel like while we're doing
knowledge work.
Speaker 4: I think that's what we should optimize for.
Speaker 5: And a knowledge work is about its about knowledge sharing
and learning new things and helping each other grow and
learning from each other. So I think I think my
programming is is the best fit for that, and to me,
it feels like it should be the normal, the normal
way working the team. And then there could be situations
where you could go for individual or solo work in
certain situations, perhaps, but I think the normal should be
working as a team.
Speaker 1: M h. Great stuff.
Speaker 2: So are there resources you point people to for this?
Speaker 5: Alrica, I would say Woody is all the book. Software
teaming would be a good a good place.
Speaker 1: What's next for you? What's in your inbox? H oh?
Speaker 4: We are going to be.
Speaker 5: Continuing on a sourcing so I was listening to your
last episode just today.
Speaker 4: Yeah, so that's gonna be fun.
Speaker 1: Yep. Good well. Thank you for bringing this topic back
to dot net rocks. It's been great and it's good
to hear that you're being successful with it, and I
hope some of our listeners are also thinking about doing this.
It's good stuff. Thank you, Thank you all right, and
we'll talk to you next time on dot net rocks.
Dot net Rocks is brought to you by Franklin's Net
and produced by Pop Studios, a full service audio, video
and post production facility located physically in New London, Connecticut,
and of course in the cloud online it wop dot com.
Visit our website at d O T N E t
R O c k S dot com for RSS feeds, downloads,
mobile apps, comments, and access to the full archives. Going
back to show number one recorded in September two thousand
and two. And make sure you check out our sponsors.
They keep us in business. Now go write some code.
See you next time. You got J Middle Vans
Speaker 4: And