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.
Oh, or alternatively, the lumpers have way more cognitive capacity than I do, so don't benefit from the abstractions created by splitting. Then I try to argue that they should write code accessible to dullards like me. Maybe that's not always true.
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.
Your list of constraints helps me balance my preference for splitting. I'm used to working in those high-trust, high-introspection environments.
The idealist in me can't help but twinge when I hear arguments of the form, "Well, in the absence of the necessary skills/culture/incentives we must...". I'm more interested in how to make the necessary skills/culture/incentives more the norm. But I can also understand being pragmatic about the current state of the world.
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.
We haven't gotten to the One Pile tidying. That's absolutely a valid TF? move. If an element has been split along lines that creates coupling, inlining _reduces_ the scope of that coupling, lets you see all the sub-elements, and enables you to re-split more effectively.
I don't really care what other people think most of them lie out there rectom and today's culture is more about shaming some one instead lift them so when it comes down to who knows more or what not doesn't matter you spreed love you get love you bully pepeople they want rid of you so I've chosen repeat kindness and love it's
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.
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?
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.
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.
On a side note, I've worked on a legacy system for 18 years, and wasn't allowed to re-design it, and people wouldn't adopt TDD or anything. It's not good. But, being the only developer (as sucky as that is), I decided to just start doing TDD, as it would increase my speed and quality at the same time, and that it did. I can't imagine turning back. TC(R) in particular really helps with rapid decouple refactoring.
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...
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, ...
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.
I have some evidence of this from talking to colleagues, whose experience has given them every reason to distrust names.
Oh, or alternatively, the lumpers have way more cognitive capacity than I do, so don't benefit from the abstractions created by splitting. Then I try to argue that they should write code accessible to dullards like me. Maybe that's not always true.
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.
Your list of constraints helps me balance my preference for splitting. I'm used to working in those high-trust, high-introspection environments.
The idealist in me can't help but twinge when I hear arguments of the form, "Well, in the absence of the necessary skills/culture/incentives we must...". I'm more interested in how to make the necessary skills/culture/incentives more the norm. But I can also understand being pragmatic about the current state of the world.
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.
We haven't gotten to the One Pile tidying. That's absolutely a valid TF? move. If an element has been split along lines that creates coupling, inlining _reduces_ the scope of that coupling, lets you see all the sub-elements, and enables you to re-split more effectively.
I'm excited to learn about One Pile tidying. (I'm happy when people find useful names to things like this, so thank you)
Thanks for the writing, Kent
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.
I don't really care what other people think most of them lie out there rectom and today's culture is more about shaming some one instead lift them so when it comes down to who knows more or what not doesn't matter you spreed love you get love you bully pepeople they want rid of you so I've chosen repeat kindness and love it's
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...
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.
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?
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.
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.
On a side note, I've worked on a legacy system for 18 years, and wasn't allowed to re-design it, and people wouldn't adopt TDD or anything. It's not good. But, being the only developer (as sucky as that is), I decided to just start doing TDD, as it would increase my speed and quality at the same time, and that it did. I can't imagine turning back. TC(R) in particular really helps with rapid decouple refactoring.
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...
I know what you're talking about. The code really REALLY wanted to be split this way. Beautiful separation of concerns.
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, ...