Making chunks is abstraction; abstraction is design. We are back in the 1950s. This is exactly how I sell "abstraction" to jaded intermediate programmers. "Remaining distracted by considering all the details all the time actively frustrates your progress. It's what makes you want to throw it all away and start again."
- we need to chunk and slice because our mind is capable of keeping only 5 ± 2 "things" in memory
- because usually our application comprehend more that 5 ± 2 lines of code, or things, we need to group them so that we can substitute in our mind a group of lines of code with a single method name
- in order for those abstraction to completely substitute the "inner parts" in our mind the abstractions need to be well sealed and makes sense to us
- leaking abstraction create problems because we cannot really substitute the inner parts with the abstraction in our mind, because we also need to keep in mind some details that leaked off from the abstraction (like remembering that we are doing something on the db or over the network).
Chunking to me resonate like bounded context or domain partitioning, slicing more about layers in layered architecture. Is that what you mean?
That's not how I think about chunking. Elements are composed of smaller elements (functions composed of statements, modules composed of classes, etc.) Those are the chunks.
The two aren't mutually exclusive. I might look at database performance (a slice) then extract an ORM (chunks).
Making chunks is abstraction; abstraction is design. We are back in the 1950s. This is exactly how I sell "abstraction" to jaded intermediate programmers. "Remaining distracted by considering all the details all the time actively frustrates your progress. It's what makes you want to throw it all away and start again."
Hi Kent, things that pop in my mind:
- we need to chunk and slice because our mind is capable of keeping only 5 ± 2 "things" in memory
- because usually our application comprehend more that 5 ± 2 lines of code, or things, we need to group them so that we can substitute in our mind a group of lines of code with a single method name
- in order for those abstraction to completely substitute the "inner parts" in our mind the abstractions need to be well sealed and makes sense to us
- leaking abstraction create problems because we cannot really substitute the inner parts with the abstraction in our mind, because we also need to keep in mind some details that leaked off from the abstraction (like remembering that we are doing something on the db or over the network).
Chunking to me resonate like bounded context or domain partitioning, slicing more about layers in layered architecture. Is that what you mean?
Thanks for sharing!
How do you differentiate between chunks and slices in mobile app development? Chunks make sense to me, but slices don't.
Nice one Kent. This reminded me of an an article that I recently read
https://www.ociwins.com/resources/blog/keep-your-sentences-short-why-shorter-is-better/
So
chunk = vertical piece of functionality
Slice = horizontal "layer" of cross cutting behavior
Would that be fair?
That's not how I think about chunking. Elements are composed of smaller elements (functions composed of statements, modules composed of classes, etc.) Those are the chunks.
The two aren't mutually exclusive. I might look at database performance (a slice) then extract an ORM (chunks).
Does that help?