[larsmak]

I've been a java developer for over 10 years (8 professionally). I've worked as a consultant on large government projects, using legacy frameworks like Struts/Tiles and being forced to use older versions of Java. I've worked for tech-startups being able to use new and hot tech. like Cassandra, jdk8, and the play-framework. And in between I've hacked on a ton of personal projects, including tech like gwt, mongodb, android, etc. I've used lots of frameworks like Spring and Hibernate. Although such frameworks often provides abstractions and encourages usage of design patterns, I've never really found my-self getting lost in their layers of abstraction, and I've can't really say I've come across any "AbstractAdapterFactoryProviderBean"-either.

I've also never found my-self working with a code-base I'd considered clean and highly maintainable. When code-bases becomes big and complex, they tend to get messy. It's hard, if not impossible, to maintain a complete view of the entire application at once - and this leads to different approaches at different times, and places in the code. Having multiple developers come and go, with various levels of skills, does not help either. Having some framework dictate the overall structure of the application limits the potential for to much diversity in the code, it also helps new developers get a grasp of the codebase if they have used the framework, or similar frameworks, in the past.

When I design a simple application, the flow is limited, and I don't need the abstractions - so I don't implement them. But when the system grows in complexity, and the concepts and logic starts to overlap, it becomes reasonable to implement abstractions. To layer the application into DAO, service, persistence layer, etc. To group common logic, and make abstract implementations. I could go on. Abstractions are good, but overuse is also not good - of-course, like everything else it's about finding the right balance.

[lnanek2]

I can say the same re your experience, but I kind of experience the same thing he links to with Gradle and really despise it. Handling the constant Groovy errors and Gradle errors, and spending my life digging through their docs for a language and a build system I couldn't care less about really depresses me when I'm a Java expert. Give me a stack trace and I'll have the problem fixed in five minutes with unit tests and UI automation tests done later that day.

But give me a gradle error and I'm stuck in their docs all day, you might have a solution this week. And by the way it breaks automatically all the time as Android Studio and the android tools plugins and all the rest version up. I wish we could have just stuck with Ant and Eclipse for Android, which are known evils. Instead every update of Studio and Gradle someone on the team has to draw the short straw and try, then either give everyone else the OK or tell them to stay the hell away from that version.