2 ms·
Awesome, thanks. I jumped into the first one that grabbed my attention: CDD - cognitive driven development (link below, 15min video). I love the premise but fi
by sethammons 3y ago
Awesome, thanks. I jumped into the first one that grabbed my attention: CDD - cognitive driven development (link below, 15min video).
I love the premise but find the recommended results silly. TL;DW: cognitive research shows humans have working memory limited to 7 +/- 2 things. This means that classes should be limited in what they do. So far, I agree. And I think this can be extended, in practice.
However, they back up this idea with a single case study and use a decorator to help count complexity to keep the classes small and state that methods not extending beyond 24 lines of code are ways to do this. This will just lead to cargo culture like "don't comment code."
The decorator is not needed because code should (authoring or in review) be obvious if handling more than 5 to 9 things. The number of lines might be correlated to the number of things a function does, but that doesn't mean cognitive overhead. Like, a 100 line function that maps state abbreviations to state names is fine.
Based on the presented data and mental performative drop off, it is not 7 +/- 2, it is really five + 0 to 2. I hereby dub this the Rule of Five.
A practical example better than what they present in the talk: early returns. Every nested block adds to cognitive load, early returns allow you to discard that load as you continue reading through the function. The cyclomatic complexity reaching over 5 levels means many people will start to fail to keep all the blocks in working human memory. Therefore, early returns are a good implementation of Cognitive Driven Development.
The case study they used seems meh. With a couple decades of experience with high growth start ups becoming "real" companies, I just don't buy their results on decorators and function line length. But they are on to something with limiting code to keep minimal cognitive overload down.
https://m.youtube.com/watch?v=g_ht_LDm5Hw&feature=youtu.be https://m.youtube.com/watch?v=g_ht_LDm5Hw&feature=youtu.be
- munchler 3y agoEarly returns provide a breeding ground for subtle bugs. I wonder if the research considered that aspect as well.
- n0n0n4t0r 3y agoNot forcibly if you keep every function short: then their structure is simple and less hazardous to read without error
- taneq 3y agoI’ve heard this before, and I can see how some cases (returning from random points in deeply nested loops or something) could cause issues, but in my experience early returns at the start of a function for error handling make things far simpler and more explicit compared with other options.
- n0n0n4t0r 3y agoAnd it seems a little wrong as developers gain the ability to use the way more capable spatial memory with time (the same as for memory palaces). So yeah, in practice, I agree to keep classes small, but not for the short term memory problem.
- sethammons 3y agoGood point: as you become an expert in the given system, you can encapsulate or abstract away multiple things into one. A silly example: when you are learning to dress yourself as a kid, zippers are hard, shoe laces are hard, putting left shoe on left food often gets mixed up. All these little details. When you are older, these details take no mental capacity and you can "get dressed" as a single concept.
- kayodelycaon 3y agoIt really bugs me when it is blindingly obvious a professor doesn’t actually know how cognition works. The actual study of human performance is outside their field, therefore untested or flawed assumptions form the basis of their research.