"... can solve those same social problems while writing FP code? If we want to avoid object oriented hierarchies and graphs that are interconnected and complect

"... can solve those same social problems while writing FP code? If we want to avoid object oriented hierarchies and graphs that are interconnected and complected, can we still address the social and nontechnical problems you think OO solves?..." I believe that's where functional OO languages like OCAML and F# come in. Do your OOAD, then construct the code functionally. Once you realize you're not going to refactor, start grouping into classes. Your OOAD helps drive your data structures out. Actual code and functionality drive your class structure. But what I'm finding is that both FP and OOP code evolves into a DSL; FP more directly and OOP in a more roundabout manner. If that observation holds up, then what we're really talking about with organizing code is creating layers of DSLs, not tiers of functionality. If that's the case (and it's a big "if") then something like a code budget and insistence on DSLs as a desired end-state might be the best way to balance both scalability (in terms of team size and effort) and complexity.