Hey there! Nat here – with your weekly edition of Simpler Machines. A little on the long side this week – lots of stuff I wanted to get out on the internet.

Is pairing good for exploration?

Last week Hillel Wayne wrote a newsletter called What Mob Programming is Bad At, arguing that mob programming (and by extension, pair programming) is really good at implementation, but kind of bad at optimization – and that it's generally bad at doing things where a lot of the work is figuring out what to do. (This isn't a perfect summary of the argument but like, go read it.)

Anyway at the end he invited people to fite him so here we are.

I don't have any experience with optimization in a pair but I do have a lot of experience with exploring in a pair. My basic opinion is that it's harder to explore effectively in a pair than it is to implement effectively in a pair, but that it can be done, and in pairs that are effective at exploring it's way better than exploring alone. Why it's harder is a little bit complicated.

I also don't think the reasons really apply to mobbing. Hillel groups mobbing/pairing together but I find that they're very different beasts with very different dynamics, so I'm just going to talk about pairing. Maybe it applies to mobbing too.

Exploring at Cloud Foundry

We did pretty much everything at Cloud Foundry in pairs, and I originally got hired at Cloud Foundry as part of an attempt to build an "exploration" practice. So I've done a lot of exploring in pairs.

Mostly it was kind of hard and awkward. Usually I would have a pretty clear idea of what we were trying to learn and why, and my pair wouldn't, and so we'd both spend the pairing session kind of frustrated – me, because I felt like I was dragging my pair along, and them, because they felt like they were wasting their time doing something weird and confusing and pointless.

Occasionally it was great. When it was great it was because my pair was also very clear on what were trying to learn and why – and would stop me and have us talk about it if they ever weren't clear.

Why is exploring in pair harder than implementing in a pair?

• Pairing requires keeping a stable goal and it's harder to keep a stable goal while exploring than while implementing
• There's a much larger distribution of exploration skill than implementation skill amongst developers (and most developers are worse at exploring than they are at implementing)
• It's harder to pair when skill levels of different than when skill levels are similar
• We have a lot of tech for supporting implementing (especially across skill levels) in a pair that doesn't apply to exploring
• There is tech for supporting exploration in a pair, but it's less well-known than the tech for supporting implementation

By "tech" I mainly mean "small stories" and "test-driven development."

TDD makes it substantially easier to pair, because "write a test, make it pass, then write another test" keeps the pair's goal in any given moment tight and stable, and creates clear points to stop and renegotiate the goal. It also gives you access to pairing techniques like "ping pong" – I write a test, you make it pass, then you write a test and I make it pass.

Exploratory work doesn't have the same rhythms so it's harder to clearly negotiate control, and you're more likely to end up in a place where you're not really pairing, you're working on the problem in parallel – and one person is consistently ahead of the other person.

If you want to bring the same level of clarity and rigor to exploring you can use a technique called Exploratory Charters, but as far as I know Pivotal Cloud Foundry is the only place that ever did this in a systematic way.

Maybe this is something I should write more about? If so let me know – I tend to assume that people aren't actually very interested in exploration and "exploring in pairs" is such a niche-of-a-niche – but we developed a lot of techniques for it at Cloud Foundry and it's probably worth writing that stuff down one of these days.

Exploring at Cloud Foundry

We did pretty much everything at Cloud Foundry in pairs, and I originally got hired at Cloud Foundry as part of an attempt to build an "exploration" practice. So I've done a lot of exploring in pairs.

Mostly it was kind of hard and awkward. Usually I would have a pretty clear idea of what we were trying to learn and why, and my pair wouldn't, and so we'd both spend the pairing session kind of frustrated – me, because I felt like I was dragging my pair along, and them, because they felt like they were wasting their time doing something weird and confusing and pointless.

Occasionally it was great. When it was great it was because my pair was also very clear on what were trying to learn and why – and would stop me and have us talk about it if they ever weren't clear.

None of this really applies to optimization

I haven't done much performance work and it seems like the dynamic I've described doesn't actually apply – the goal of performance work seems like it's pretty clear the whole time. So maybe performance work is a different case from exploration.

The skill variation does, though – my expectation is that it'd be much more productive to do performance optimization work in a pair where both people were relatively equally skilled at it.

Does anyone really Tidy First?

I read a review of Kent Beck's latest book recently by Will Larson. He made a comment that really surprised me and also really really shouldn't have.

I’ve never seen a team that works this way–do any teams work this way?

A little further down Larson asks.

Curious to see how many teams end up adopting this approach, and what makes teams likely or unlikely to adopt it. Is this an approach that mostly works for small teams in code that is already modular? In small monoliths? In large monorepos? We’ll see what the industry takes from it over the next few years.

Hoo boy.

1. Cloud Foundry worked (and largely still works!) this way.
2. It works for large codebases split out across many repositories.
3. It works for codebases that are messes, and will slowly improve them over time, with patience.

Since Cloud Foundry is open source this means there are hundreds of examples of the Tidy First? approach in action in its Github organization.

Try taking a look at this 15,000 commit bad boy, written in 100% artisanal free range Ruby. Note how many of the commits (that aren't version bumps) include refactors or are little cleanups. This is typical of how Cloud Foundry develops code and has been for a decade.

Learning Elixir

I'm back on the Elixir train – trying to really get the Phoenix/Elixir combo. I've spent most of my career learning just enough of various frameworks to get by in an existing codebase and am starting to feel the limits of that as an approach. So I'm spending at least a little bit of time trying to get some depth for once. - Nat

To that end I'm writing a few notes here on what I tried, what was hard, and what I'm going to try to learn to make it easier next time.

Three things this week that I spent a lot of time struggling with:

• Making decisions about how to structure database schemas
• Implementing those decisions in Ecto
• Debugging tests (that turned out to be working fine, I was just confused about what the right behavior looked like)

I've got a copy of Programming Ecto on my desk in front of me right now. My next move is to read that pretty much straight through and see how Ecto feels after that.

Man there is so much happening right now. The Pivots newsletter kicked off a lot of ideas and interviews and just – work. It's good but it's all a little bit of a jumble. Some of it is just it's that time of year – more light, more evening light, and suddenly my brain is on.

- Nat