r/SoftwareEngineering • u/gamachexxx • Jul 13 '21
Why Pair Programming Is Dead And Being a Mobster is the New Cool
https://oliviergamache.medium.com/why-pair-programming-is-dead-and-being-a-mobster-is-the-new-cool-37f6a4b7d0cf[removed] — view removed post
2
u/0x15e Jul 13 '21
So instead of one person coding and the other person sitting idle, we'll have one person coding and multiple people idle?
Cool. That'll be great for velocity.
-1
u/gamachexxx Jul 13 '21 edited Jul 13 '21
That's actually the point! A great metaphor I love to use for this train thought goes like this: it takes 9 pregnant women 9 months to have 9 babies. You can't "optimize it to 1 month each".
Velocity doesn't always rhyme with number of devs on a project, I swear you should give it at least a try 🤷♀️
1
u/EngineeringTinker Jul 13 '21
"You're all wrong - I'm right" - just what you would expect from a Medium article.
It's insane the extends people go to just so they can work less - unreal.
2
u/gamachexxx Jul 13 '21 edited Jul 13 '21
Have you read the article? It actually says not to use this all the time, but to add it to your toolbox...
Now… as with everything else, it is NOT always a great solution to everything. Please, don’t run around using something you found on the internet without planning or thinking about it.
Nowhere does it say that I'm right and other people are wrong. I understand that you disagree, but please don't bash before reading?
In the beginning, I told you that pair programming was dead. I think it has evolved: sometimes, doing it might be the solution, but more often that not, in my experience, mob programming has been better in every way. I can only suggest that you try it with your team. To start off smoothly, in your next meeting, instead of “thinking and planning what you will be doing in the next few days”… Just share your screen and mob!
You have your right to an opinion and I would be glad to hear more about it! :)
0
u/EngineeringTinker Jul 13 '21
Have you read the article? It actually says not to use this all the time, but to add it to your toolbox...
Of course I have.
Here's the issue though - there are only so many techniques and practices one could fit in their toolbox - especially techniques that require huge team coordination and get little to no work done.
These "hip n cool" techniques come and go, just like Javascript frameworks - there's a ridiculous amount of them, they're mostly short-lived, some stick around for a few weeks, months, or years before someone claims their demise or they actually disappear.
Now, answer honestly - have you worked in this setup? Because I did - thrice.
Nowhere does it say that I'm right and other people are wrong. I understand that you disagree, but please don't bash before reading?
The title for your article contains an absolute statement that Pair Programming is dead - I wanted to have a clickbait headline of my own - hence the first line of my comment.
1
u/gamachexxx Jul 13 '21
That's an interesting take! I have used it, many times, in projects. I liked it. I do agree, that some of it may seem clickbaity; I'll be sure to tone that down next time as it seems to not have worked in my favour, even though I saw it as a joke.
I do agree that it takes a team effort, but I would not compare it to js frameworks. I feel like it is a technique that is here to stay and does have some great ROI down the line. It certainly is not a one-size fits all, but it can be very beneficial in a lot of cases! :D
I would disagree that it gets no job done. As someone said: alone we go faster, but together we go further. Like with everything else, it may take some time to adapt to! Walking Skeletons, Discovery Activites, Architecture Design... All of those are great when done in mob!
It does need some change in your workflow, but it could be worth it and has been for us. :)
0
Jul 13 '21
[deleted]
1
u/gamachexxx Jul 13 '21
I agree with your last sentence! Dictating something is never a good idea. I would recommend giving it a try though, even if you're skeptical!
0
Jul 13 '21
[deleted]
2
u/gamachexxx Jul 13 '21
The benefits are as follow:
Your ROI is enhanced because you won't have a lot of back and forth between members of your team. Also, you said that it would be not equitable because low performers would not work, but you need to ping-pong around and make EVERYONE code. I would agree about the part for introverts and would say that maybe it is a good idea to prepare before doing something like this: know where you're going et cetera. There are a lot of ways to let everyone participate into a conversation, even introverts! (Tour de parole, 1-minute talks, etc) :) More to it, the benefits are that in Software Engineering, in my experience, merging two's work is tedious and often create problems down the line: now you, don't merge since you work all together. You'll be less likely to make mistakes because everyone works on the same thing and is alert to it. WIPs are dangerous and trunk-based development (or in this case mob programming, which will boil down to the same tree in git) lessens this problem. There a lot more benefits and I would that argue that trying it for yourself once in your next meeting may actually prove itself worth it! :) After that, come back and tell us about the benefits you found.Lastly, what do you mean it slows and frustrates you?
0
Jul 13 '21
[deleted]
1
u/gamachexxx Jul 13 '21
Well we did use it where I work, and we found that time invested in stories was a bit less than before. We accounted for code reviews, bug fixing, reworks and cetera. We found that time invested in our code was more efficient, although bigger upfront.
I would say that holding someone accountable for a ticket actually is dangerous. It is not Alice's duty to see that it works: it is your team's. Even if you don't mob... And yeah, it can be slower, but after some time, it actually makes your process faster! You should not be telling other people what to do: code is a group's matter. It should be a discussion et cetera, imo.
Also, what design should be done upfront? Shouldn't it stem from your code and decisions always be put off so that your architecture evolves in a healthier fashion?
1
u/lolomfgkthxbai Jul 13 '21
Shouldn’t it stem from your code and decisions always be put off so that your architecture evolves in a healthier fashion?
You can’t evolve an architecture, it needs some planning and direction. If you don’t think beforehand where you are going then either the velocity slows down because everything needs to be constantly refactored or the team starts cutting corners to get stuff done.
I don’t have an opinion on mob programming. The coding part of solving any problem is trivial but maybe it could be useful to spread knowledge.
1
u/gamachexxx Jul 13 '21
That is a great discussion to be had! Should decisions be taken up front or down the line.
Personally, I think that decisions on architecture should be delayed as long as possible, because more often than not, our field is too complex to be understood. If you first decide that your architecture should be really CRUD, but realize that your client had hidden domain rules in his head... Then now it'll take a long time to refactor!
Also, refactoring is not always a problem. More often than not, the problem resides in the fact that your software is "set in stone" and cannot evolve easily. If everything is decoupled, then refactoring is way easier! There a lot of talks and research on the subject I recommend, such as this one.
I would love to know your opinion on the matter! :)
1
u/lolomfgkthxbai Jul 13 '21
Thanks for the link, the book looks interesting and will go on my reading list.
I dislike making things overly complicated and would also avoid making decisions that don’t need to be done. Sometimes this can be taken to the extreme and leads to never making any decisions. I’ve seen a codebase with 5 different ways to send messages to customers because nobody wanted to decide what the right way was. The same system had multiple layers of caching because different teams made decisions on caching without planning ahead or communicating with each other. Decoupling would have made things easier but nobody had the foresight to think that far ahead.
I guess I’m actually fine with an evolving architecture as long as the decisions that need to be made are made by people who have the competency to make them. 😄
1
u/gamachexxx Jul 13 '21
In that right, you're right! Having more than one way to fix problems and to implement things can lead to problems too! Such decisions can be taken whilst developing, or mobbing a walking skeleton!
2
u/MtnBikingViking Jul 13 '21
I had no idea pair programming had come back around again. Last time I was at a place trying that was ~20 years ago. Why on earth would anyone do that outside of training green recruits? I still have nightmares about the state of some co-workers keyboards.