
How Cucumber Open Source Maintainers Do Mob Programming - fagnerbrack
https://www.infoq.com/presentations/distributed-teams-remote-collaboration
======
pg_bot
The premise of Mob Programming[1] seems ludicrous to me. I can't imagine a
scenario where this would be efficient in creating a product. The irony of the
concept is that it is sold along "lean and agile principles". Has anyone found
success using this model?

1: “All the brilliant people, working on the same thing, at the same time, in
the same space, and at the same computer.“

~~~
sillysaurus3
FWIW, the justification is interesting. From
[https://thecuriousdeveloper.com/2013/09/15/get-a-good-
start-...](https://thecuriousdeveloper.com/2013/09/15/get-a-good-start-with-
mob-programming/)

\---

Why we tried it

When asked to implement a rather big task, like an epic, you’re often in a
state where you have a pretty good picture of what needs to be done on high
level, but on a lower level it can be very fluffy and unclear. Fluffy enough
to stand in the way of being able to ”slice the cake” in nice, independent,
deliverable user stories. Fluffy enough to give us problems if our aim is to
have a structured, ordinary sprint backlog prepared, and to burn that backlog
down continuously by developing small software increments for a couple of
weeks. You know you’re in that fluffy state when:

\- Someone asks where a good place to start this epic is and all possible ways
you can think of are either intertwined and far from independent steps or just
one big mega user story

\- You get a urge to just start coding, hack away for a while and see where
you end up

\- You may even wish that you, for a while at least, could forget everything
related to user stories, epics, backlogs and burn downs and just do some
Programming, Motherfucker [http://programming-
motherfucker.com/](http://programming-motherfucker.com/)

\---

Now, _if_ this technique can supposedly solve that critical problem -- and it
is critical; I spend >N% of my time in that sate -- we should give it the
benefit of the doubt and just try it.

It sounds like the point is to spend a couple hours in an environment where
forward progress is always being made every minute, yet freedom has been
completely removed.

I think I'd volunteer for that, to be honest. It's so nice working from a
designer's mockup rather than trying to design + build the whole app
simultaneously. That same feeling might apply here.

It's kind of compelling. But only if everyone actually wants to do it.

Think of how much time we've all wasted fiddling around with design, moving
property lists around, exploring new approaches, or throwing in an hour of
metaprogramming only to find out it reduced our line count from 150 to 100 and
made it quite a lot harder to read.

If you tried to pull any of that during one of these sessions, you'd get
called out immediately.

Oh yeah: [http://hackthesystem.com/blog/why-i-hired-a-girl-on-
craigsli...](http://hackthesystem.com/blog/why-i-hired-a-girl-on-craigslist-
to-slap-me-in-the-face-and-why-it-quadrupled-my-productivity/)

You know, this really should be a thing. I wonder if devs would pay for this?
I'd give someone $20/hr to keep me on track. But they'd need to know enough
about programming not to be annoying or blatantly mistaken.

~~~
nerdponx
Mob programming sounds like a goofy nerdy substitute for "getting a meeting
room and figuring it out on a whiteboard".

------
megamindbrian2
You could add Google marketing tracking and get some insights into who uses
it.

------
throwaway284534
This may sound a bit snarky, but does anyone here recommend Cucumber tests?
I've found they add a lot of overhead to writing without much benefit. Non-
technical employees can't really write them either so they be revised by a
developer. If that's the case then we're back to where we started.

~~~
triskweline
We're heavy users of Cucumber at our development agency. I've never seen non-
technical users write Cucumber scenarios either, but we find them very useful
for another reason.

The problem with test suites is that, as they grow and age, it becomes harder
and harder to understand why tests are testing what they test. When a years
old test fails because 5 is not 7, you cannot really fix it unless you
understand why it was supposed to equal 7 in the first place.

Cucumber is a way to describe requirements at a higher level of abstraction.
They provide rationale on top of mere assertions of behavior. This is worth
the small overhead of writing step definitions.

I guess you can get the same by heavily commenting your tests. But you cannot
enforce this easily in a team.

~~~
choward
Nothing is stopping you from using functions with descriptive names without
cucumber. Cucumber forces you to write functions (steps) however you can still
create bad descriptions just like function names. Cucumber just allows you to
define functions using a different syntax than the language your using. I
don't see any wins here.

~~~
maxxxxx
That has been my recommendation when people started talking about Cucumber at
my compnay. Write a library that has super descriptive names like
"EnterTextIntoPriceField(400)" and you get the same benefit Cucumber gives you
but you have real programming language if needed.

Our biz people can't write useful requirements so I doubt they can write
meaningful Cucumber scripts either.

~~~
jondubois
I worked for a very large company that started rolling out cucumber. It didn't
go anywhere - Product owners simply did not have the technical ability to
write cucumber tests.

I think that they add way too much complexity. It doesn't make sense to try to
write technical software tests at such a high level of abstraction.

When you try to test something at a really high level along the lines of "As a
user, when I click on X, I want Y to happen" the low level technical
ramifications of this can be enormous.

There is a huge amount of underlying complexity which the one-line sentence
simply cannot capture and which is prone to change and needs to be tested
separately... Probably not in a way that a non-technical manager would
understand unfortunately.

Ultimately the tests are not granular enough to be useful as tests for
developers and they have too much overhead to be useful as documentation for
non managers.

