Hi Gabor,

I’m not waging war against anything. Just because I don’t sell myself 100% to a tool does not mean I find it not useful. I like DI and I will always use some of those libraries.

But indeed the idea against some of the things I raised is not new indeed. If I’d show this article to developers from the Software Crafter community I’m getting a lot of agreements. It’s just the way many of them think too. Clean architectural layers, separation of concerns, and wrapping any third party library or not been tied to any language or framework are core principles for many of them.

Neither are those the majority nor do they have a strong base in the Android community, unfortunately. For years testing wasn't an issue and DI was ignored. Later both came with sometimes questionable approaches (Roboletric anyone?).

Libraries often give us features that are can be useful but often are actually a smell. When you see someone injecting a Map or a Set the only proper expression should be: WTF!?
Object orientated design, Polymorphism, primitive obsession, leaking abstractions, many patterns and anti-patterns should come to mind here. I’m not saying there is no reason ever for this feature, but in most cases I’ve seen it should be avoided.

I guess we can not deny that the majority of codebases are mediocre, its the big problem of our industry that ultimately will lead to the software apocalypse and has been discussed many times.

But those codebases often drive features of libraries and tooling that should not be there in the first place, in the article you linked, the author quotes “wisdom of the crowds”. That does not make it right!

A good example is the easy ways with that Mockk allows deep mocking. Its great API but a dangerous feature that will create more harm than good. The need for the deep mock is the smell and a stinky one. It’ s exactly why Mockito Kotlin never introduced it although developers keep asking for it.

So I’m not waging war but please question every feature, I’ve seen too many applications that had to be rewritten as refactoring was impossible, and having a tight connection to libraries is often part of the problem.