Engineering Overkill in Java

This is just an informal poll/discussion, if anyone is interested. I'm in a position where I need to think about this stuff a lot more lately and I want to avoid being in my own echo chamber.

After almost 30 years of Java "lessons learned" (hopefully), is it fair to say that most experienced Java devs have learned to take it easy with all the...

- Frameworks (or custom "sub-frameworks")
- Over-engineering
- Abstractions / facades
- YAGNI "just in case we need it"
- Deep inheritance structures (i.e. prefer composition over inheritance)
- Over-use or eagerness to employ "patterns" (or other trendy stuff)
- Add your own if you want

I've definitely taken a turn in recent years (5-10) to keep things more on the simple side, and only add complexity or verbosity required to follow many "best practices" when it's obviously needed. I would say it has worked out fairly well. Being careful not to over-build, and only employing popular paradigms or certain expensive 'best practices' where you see an obvious improvement from them at the very least tends to give you a smaller code base, in my experience.

Anyone feel differently (or the same)? Or are we still over-engineering stuff?

While I agree with the philosophy of YAGNI, I often still find myself falling into the trap of over-engineering parts of my application. Practice and preaching are two different things!

A stupid thing I do is start a project, work on it until I've spent too much time on parts that I don't need right away, create a Git branch to backup the extra bits, and then throw away everything that is not necessary for my next immediate goal.

I find that Test Driven Development helps prevent this, but the problem with TDD is that it feels like a lot of overhead if you're just trying to write a quick and dirty bit of code to prototype an idea. Of course, if you're just prototyping, then you're probably not doing a lot of engineering in the first place.

Having a backlog with user stories also helps prevent over-engineering. If you focus on implementing one user-story at the time, the temptation to design more than you need is reduced.

While it is inevitable sometimes, I find important not to fall into the traps of workarounds and rather stick to officially supported features, whether it is of a framework you use, or cloud provider services, or something on that line when you develop your system.

And if you find you need a workaround, that's not necessarily what you indeed need to do, worth speaking with product by explaining consequences of a, b, and c, so it may appear that that something might not that important after all - so you avoid over complicating parts of your system.

I've become pretty ruthless about throwing away code when I start to think it's over engineered. The fact that you can toss it into git and forget about it helps a lot, and I do the same. I think as long as it's removed from the latest real branch, we're good.

Ahh... "workarounds" - i.e. monkey patches/technical debt/etc. I wish we had an easy solution to prevent that stuff. The only real strategy I know is to eliminate it after it happens, put aside the time to refactor and improve on a routine basis. Very hard to do in an environment where you're always putting out fires or on a super aggressive schedule.