RE: https://hachyderm.io/@ZacSweers/116101250172764107 I've been following this discussion popping over and over within the #androiddev community for more than 10 years. As a former member of this community, I also have something to say. "[...] Then after a certain level of complexity I find myself annoyed with the wiring and adopt a DI framework." Repeat after me : there is zero chance a DI framework may be simpler than manual wiring for any project, Android or not. By automating annoyance, one chooses compound more complexity (and build overhead) on top existing complexity (and existing build overhead). I'm all ears for a compelling counter argument framed on *simplicity* here, but I think I'll get none. Since v1.0 Kotlin delivers already a good set of features that enable better ergonomics for manually wiring dep graphs (code) and production code. I once implemented something like https://arturdryomov.dev/posts/a-dagger-to-remember/ in one large greenfield project, and I could see it by myself it works. The team was happy, the product scaled, the project too, and we could rev walk dep graphs of a module using IDE features. My gosh ! Kotlin enabled that almost a decade ago, but people refused to see, treating all boilerplate as equality bad. Nowadays, for large multi-year old Android code bases, the reality are several lines of custom annotations no one understands decorating a single constructor or function. I call this boilerplate too. Over the years, I've compared the number of LoC before and after a clean build in all sort of Android projects I worked, just to learn that Dagger and friends was doubling, some times tripling the total LoC. And people never understood why a cold CI release build took one hour to complete during a hotfix deployment .. I always argued that, with Kotlin features + manual wiring, having the same amount of LoC for dep graph code and prod code is pretty impossible. I invite someone to take a project like NIA and use some LLM to generate manually wired IoC, compare total number of LoC, and conclude by himself/herself. I don't have the time or interest to do that at this point. ThePrimagen says on his videos : "code is liability". I agree with this statement. Android devs seems to forget that code under build/ folder is liable too, validated at compile time or not.