@ZacSweers@hachyderm.io I disagree with everything you said. Your counter example only works for naive setups and small projects. It elaborates around easiness rather than simplicity, and here I refer to Rich Hickey classic "Easy made Simple" talk on the subject. Dagger does not enforce one way of doing DI, hence it is not simple. And regarding being easy, as soon one has a big multi module project with a non trivial brow DI setup in place, the reality shifts from "add one parameter to this constructor and done" to "let me troubleshoot Dagger output again", which defeats the original purpose every single time. Btw, the annoying refactor you just described with manually wired code is now handled by LLMs at scale. Such systems are just amazing for this task. In addition, by refactoring glue code with LLMs one can finally think about who ows the glue in the first place, since one should own what one ships. I brought the argument of LoC to frame how massive is the overhead of delegating code that is boring but not hard to write to a DI tool. It has nothing to do with build systems : only Platform Enginners have to engage with Gradle classpath pollution issues in large Android projects. Unfortunately, every single Engineer carries the weight of bloat generated by Dagger at compile time. That is the reality. Glad that you mentioned productivity as a factor of iterations. Unfortunately the reality of most Android projects serving users in production US : we don't have the new fancy DI tool in the town in place. The reality is having a mixed setup of Dagger and something else, eventually a project like Anvil (which is now vaporware) making people frustrated with super slow build times, build caching that does not work as it should, and massive cognitive overhead for a problem that should be simple : create instances and pass them around. I don't expect convince you to agree with me. But the arguments you provided did not convince me either.