I really liked the "ad hoc confused with flexibility" bit and the bandaid analogy. The latter is a really good metric for a lot of things in software, I think: large surface area is generally not going to do you any favours, whether it's points of coupling or API size (although I guess arguably a larger API introduces more points of coupling :thinking_face:) On the former, that's something that's been front of mind for me recently. I was reflecting on what makes DI frameworks in Java hard (in a cognitive overload, treasure hunt sort of way), and I sort of concluded that it's because of the lack of "index". When I talk about it, I've noted that (despite learning about the desire for high cohesion and low coupling in school, which made the two sound orthogonal) heavy use of DI frameworks can decouple things so far that you lose cohesion: you have no clue what connections exist or how the pieces fit unless you step through everything. Note here I'm talking specifically about the style of DI-all-the-things using @Inject on all the constructors and letting the framework autowire everything. This feels very much like the difficulty you guys mentioned with redelay. Different paradigms, exactly the same problem: you gain "flexibility" to just plug new code in and have it work, but at the cost of not really understanding where it plugs in or the role that piece plays in the broader picture. Was the flexibility worth the cognitive cost? More often than not, I think the answer is no. Am I getting old?

@U04RG9F8UJZ I think you've nailed the issue. You have to look all over the place to know where things are.

I like to think: "How much do I have to read to get the big picture?"

Of course, some of this can be addressed through documentation, but since documentation doesn't have to be correct for the code to work, I find that it doesn't age very well.

(For what it's worth, Nate and I sometimes call it a "table of contents" and sometimes an "index".)

Thanks for the feedback!