18 Comments
Feb 27, 2021Liked by Kent Beck

My theory, with absolutely no evidence beyond intuition, is that lumpers have had bad experiences with poor naming, that required jumping all over the code to see what was happening. Now they want to see all the code in one place because they don't trust code that they can't see. Of course this is a good way to justify my splitter habits.

Expand full comment
Sep 24, 2023Liked by Kent Beck

I have absolutely had bad experiences with poor naming and it's made me more of a lumper. And bad experiences with bad tools, *also* making me more of a lumper. Give me a big text file with a high percentage of all relevant code and I don't *need* to trust names or tools, so I don't need to worry whether they'll work.

In some sense that means a high-trust environment "should" be better. With good names and good tools, surely I shouldn't need to verify. But it's not just bad naming and bad tools. There are also subtle bad interactions of other kinds, and the fact that humans (reasonably, understandably) tend to read a thing's name instead of its definition and not see "this doesn't do what it says it does" bugs.

Splitting is great, assuming a long list of things that may or may not be true. And one of my least-favourite things in the world is arguing about whether a tool is good enough I should always trust it, followed by a long and bitter list of "yes, well, okay, it caused that problem for *you*, but it doesn't do that *in general*." Ah, Eclipse, I do not miss you even a tiny bit.

Expand full comment

Great Article! I oscillate between the two. I tend to like to split wherever possible... but sometimes I don't have the name(s) for that which is being lumped. Sometimes when things are lumped I find it easier to clean, not always, I'm learning...

If the things that are split out are doing too many things, I usually start by inlining them where I'm working... so they become lumpy at least for a second.

I try not to let "good code" be the enemy of "slightly less terrible" code.

Expand full comment

Deep one, thank you!

P.S. As a non-native speaker, I found useful to understand "Lumpers & splitters" term also from the Wiki https://en.wikipedia.org/wiki/Lumpers_and_splitters.

Expand full comment

This illuminated an issue I have - my good friend and the owner of a company I work part time for is a lumper and I am advocating splitting...

Expand full comment

A product need a ~ consistent style and a logic to balance these aspects. At the same time, this style could be adapted to various context zones of that product.

Expand full comment

I really appreciate this anecdote ! Not only does it give a specific example of a really common dynamic, but also it gave you the opportunity to do one of the things you're so good at: naming these tendencies. "Lumpers" and "splitters" feel really evocative to me 💯Part of what I like about the names is how they imply that these are characteristics about individuals: you tend to be one way or the other (though, I think, that doesn't mean you can't learn the "other" techniques). It's probably good to recognize this about yourself and to be on the lookout for when you are doing something just because it feels familiar and not because you consciously evaluated it as a better route than some alternative.

Also, the discussion about tradeoffs and your recognition of the value of speaking the language of the "other" perspective strikes me as a really important social element of working collaboratively that lots of people tend not to consider. You didn't assign any value judgement when describing the tradeoffs, which was probably intentional on your part; I think it would be simplistic to characterize either perspective as better than the other in the abstract. However, do you think that there are different specific contexts in which these perspectives would help or hinder the people working in those contexts? Taking the example of your anecdote, we can describe the Excalidraw context in terms of:

- customer expectations: free, open source product (not beholden to paying customers' needs or contractual obligations);

- domain area: visual/drawing/graphics may mean that manual/visual testing provides better and/or more rapid feedback than isolated, automated tests (though this may ignore non-visual infrastructure that I'm not aware of)

- stability of the mix of developers (which I have no idea about for this project)

- ...

In the past few years, I've started to lean towards thinking that that environmental context may be more important part than the inherent tendencies of individual developers (though, maybe I should limit the validity of my "theory" to *my* working context: regulated field with significant implications for "correctness" in the software; long-term paying customers; project teams with frequent changes in membership and (sometimes) a hand-off between original developers and maintainers).

How much do you think this environmental context matters (relative to the inherent tendencies of the individual developers involved in the project) in determining the fitness of the lumping/splitting mindset to the project?

Expand full comment

Maybe for testing an idea lumping is good enough, but as soon as complexity arises splitting, separating concerns, or making things simple, whatever it is named, splitting is the way to go. I'm a splitter from the beginning.

Expand full comment

I'm completely fine with both, in terms of being able to understand stuff and get work done. But I think being a splitter is superior. I suspect there must be a way of explaining to lumpers how/why they need to be splitters. I think GeePaw's explanation a week ago about needing to have an example code base setup for TDD would help with that. After one goes through TDD with TC(R), how can they ever turn back? It doesn't matter if you can handle the complexity, tight coupling, bad cohesion, etc, you're faster without it and TDD pretty much requires that.

Expand full comment

Is this a case of Lumping vs Splitting, or just a case of attempting to split things down the wrong axis, creating unnecessarily complex dependencies? I know I've done that myself many, many times, and had to start over...

Expand full comment

The good thing about the forth and back between fewer and more subelements is that by your first refactor maybe the folks applying the subsequent refactor were able to understand the relationships better and leave the code in a more understandable state than before, I would even dare say that if somebody else refactors again trying to extract from App this time the relationships would be even clearer.

I sometimes go like this on my own too, splitting, then after a while lumping back, and then splitting again, ...

Expand full comment