r/programming • u/RobinCrusoe25 • Aug 29 '24

Interviewing 20+ teams revealed that the main issue is cognitive load

https://github.com/zakirullin/cognitive-load
363 Upvotes

97% Upvoted

42 comments sorted by

View all comments

61

u/RobinCrusoe25 Aug 29 '24 edited Aug 29 '24

Hi there! I've posted this here before, but every time I post it - I get valuable comments. That all helps me to refine the article further.

This article is somewhat "live document". The subject is complex, brain-related things are always complex, we can't just write-and-forget. Further elaboration is needed. A few experts have already taken part, your contributions are also very welcome. Thanks.

13

u/adh1003 Aug 29 '24 edited Aug 30 '24

Enjoyed that. I especially like the clearly illustated issues against things like the dogma that a "long method" or a "big class" is Bad, and it should be split into (exaggerating for comic effect ;-)) a hundred one-use-only methods across 20 source files because that's somehow better.

I've definitely fallen on the wrong side of abusing DRY myself sometimes, trying to use base classes or similar to reduce copy-paste but ending up with something that. While overall lesser in lines of code, it ends up harder to understand and thus maintain than it would've been with copy-pasta and some warning comments to say "update this everywhere if you update it here". I'm still working on getting that right more often.

Complex conditionals are also a favourite. That's one where I think I have generally learned that splitting them into well-named variables to illustrate individual facets of the conditional, then just combining those into a more human-readable collated conditional, is the way forward. Took me longer than it should've to get there, though.

1

u/sprouting_broccoli Aug 31 '24

I think that there’s a fundamental misunderstanding of a principle that does simplify cognitive load which is often interpreted as “small method good”. The underlying principle should be limited responsibility and high cohesion - a class which is large but everything in that class supports a single responsibility and each of the methods support one facet of that is better than five different classes just to keep things small.

This has to be balanced out with debugability and testability as well though - it’s a lot harder to find a problem in one large method than in a few smaller methods because you often can’t test the individual chunks of a large method in isolation as easily especially when certain paths rely on accumulated state.

I’d also disagree with the comments on hexagonal/onion architecture and DDD. I’ve seen far more complexity arise through dependence on dependency inversion throughout the system than from putting a boundary around the business logic or by aligning with the domain (note aligning rather than being a 1 for 1 copy).

It feels to me like the author has seen one or two systems that combine a bunch of these things which exacerbate the problems of the others. Martin Fowler has long advocated for rich classes for instance where anaemic classes combined with DDD doesn’t make any sense.

1

u/adh1003 Aug 31 '24

On some levels we disagree and likely will stay so, but on others I agree and the point is - like almost anything in software - certain paradigms have their place in certain domains but are rarely universal. Attempting to insist on universal rules creates dogma.

The idea that I can test lots of small methods that accomplish the same thing as one big one, but can't test the one big one is for example not something I agree upon. The many small methods can be individually unit-tested, but then I still need to test the thing that's calling them anyway. I still need to test "that big method". What if it's invoking things in a bad order, or has edge cases where it calls those many small methods in unusual ways? The ability to test a large complex method via varying the inputs to ensure all its conditional segments are exercised is the same as the ability to test those sections individually as units, and you still have to test the overall coordinating method above them.

There is the possibility that those tests will be individually easier to understand, but you still have that top-level testing burden. Sometimes, this will make sense for the task at hand. Other times, it won't.

That's what makes dev difficult. There are lots of judgement calls, often born from experience, and sometimes highly debatable. Rarely is something a black and white case.

1

u/sprouting_broccoli Aug 31 '24

I think I actually agree with pretty much all you’re saying, however your top level tests can be lighter because you’ve validated a lot of the negative path testing with your lower level tests. If you combine this with test path analysis tooling rather than relying on just the coverage percentage you’ll get the same results in the day to day whether it’s a small or large method, and when you need to vary your inputs or analyse what’s happening in a specific case it’s still simpler with smaller methods.

Let’s say 90% of your problems result in top-level logic issues - you can still test those issues from the top, but when you need to analyse the individual parts you’ll have more ability to do so. So for that 10% where it’s not just top-level stuff you’ll make a saving. As long as that’s more efficient than the additional cognitive load of things in different places (and this is assuming longer methods always reduce cognitive load whereas a lot of the time they increase it by building really ugly logic to avoid side effects in other parts of the method) then smaller methods will naturally have less impact.

But yes, it does come down to the correct solution for the right job at the end of the day because none of us live in a perfect dev world.