Really good post. I can relate to all the points you mentioned. Last week our team had a board game night, we played Terraforming Mars - it was a good moment to connect outside of usual work.

P. S. I took your idea from your XP book of having values, principles, and practices into my work. We had a session with the team where we put those down in writing - it has been immensely valuable for us, thank you.

Expand full comment
Oct 24, 2023Liked by Kent Beck

Can I submit an MR to remove the "s" from the first "programmer" in “I’m a programmers, you’re a programmer, our work affects each other.”?

Expand full comment
Dec 2, 2022Liked by Kent Beck

Is the lumper/splitter dichotomy an instance of a larger class of fundamental disagreements about what good code and good design look like? There seems to be no end of these.

Expand full comment

Do you have others in mind?

Expand full comment
Dec 2, 2022Liked by Kent Beck

As I say, I've seen a lot: amount of commenting desirable, adherence to documented design patterns, bracketing/indenting styles, levels of defensive coding, centralizing vs localizing constants, the appropriate use of frameworks. I'm sure there's more I'm forgetting.

Expand full comment

👍. Lumper/splitter seems like a coarse (if apt) division. The idea that there's an unavoidable tension between different aesthetics/design styles is arguably stronger and more interesting. But maybe lumper/splitter is a good way to generalize and exemplify.

Expand full comment

We need to find some concrete ways to build this "shared..." approach. In my experience, working collaboratively is essential. Each team member will have their contribution and the results will be better. Collaborative work and continuous improvement is even better.

As basic principles, a vision adapted to the context is needed on how the design is kept clean and how it evolves.

Expand full comment
Dec 3, 2022·edited Dec 3, 2022

A word I started emphasizing more recently is "strategy". Why do different political groups, from the same side, that share the same end goal, can be fighting so much on what to do. Because they disagree on the strategy.

Even for a shared target, there are many different strategies, many are possible, but with a lot of unknown on which one would work or not. What it will look like depending on a strategy, which strength and weaknesses can sometime be grasped. But is it necessary, is it going to work at all, is not as clear.

We are trained for competitive environments, where the best strategy wins over the not as good one. So fighting over strategy is important, because it is success or not. In a cooperative environment, with many actors, strategy has a way different impact and should be addressed differently.

Some started noticing this and describe their reviews as "personal", "style", "how I like it", "nitpick" instead of principle of this must be done differently.

Does the code work, yes. But there may be issues in the future if we need to do A B C. Is it worth or not putting more effort for this? It might bite us if we don't, or we may spend a lot of effort for nothing practical, it's strategy. You do not need to sit on your principle to accept that code you do not like (for good reason, of course).

Then you can describe more what are the strength, weaknesses you see in your strategy compared to the other one. And you can more easily comply to another strategy, as it did not affect your values, just the way to reach them.

Expand full comment

For years, I have paraphrased "Zen and the the art of Motorcycle Maintenance".... Regarding the question "Are you a good welder?" there 2 contexts:

* The production line welder who knows ahead what's needed and perfects that over time.

* The repair shop welder who never knows what's coming up next, yet gets the job done.

I've used this set up many times to set up discussions in training classes.

I have often contrasted "good welder" with "good actor" by comparing a good Shakspearean actor (who repeats 400+ year old lines) and an improv actor (who says lines that didn't even exist at the beginning of their sentence).

You've just added many more dimensions to that discussion. Thanks!!!

P.S. I shared the welder distinction at a software mender session earlier this week, and someone (who was not even born when the book was popular) gave a new take on my well-worn story --

> The shop weld becomes the production weld.

He nailed it! And gave me insight into my own story (which built on the stories of other bards - William Shakespeare and Robert Pirsig).

Expand full comment

At a _different_ software mender session, the facilitator presented a framework that helps him make culture changes stick. My interpretation was to hold BOTH sides at once, looking to replace EITHER-OR (false) dichotomies with BOTH-AND answers to what some would call "Wicked Questions" or "Wicked Problems" (e.g. how to raise kids to be committed to the family and also independent people).

Some software examples were...

* How can we BOTH release more often, and also maintain stability?

* How can we BOTH use new tooling, and also preserve the working infrastructure?

* How can we BOTH let the old build system think it is the source of truth even as new code is kept exclusively in the new system?

Expand full comment