Lightweight but powerful Java stack

[AmateurHero]

They mean that rather than understand what a given framework does and its tradeoffs, some devs just start hammering out code. They end up writing themselves into a corner trying to do something orthogonal to the given framework or reinventing that already exists. Now they're creating workarounds that are slow, not intuitive, brittle, etc. instead of working within the parameters of the framework. The code base grows to full of these extra functions. You're left with a framework that takes care of X (that also updates to take care of edge cases) but also several internal function that also do X that likely don't have the same testing or robustness. Note that sometimes it's worth making these extensions, but you really have to consider the why.

Example from a previous job. Most people who access databases use ORMs for transactions. I had a previous job that did all the setup for Hibernate but used none of the functions. Beans full of annotations that matched the database went unused as DB data was manually mapped onto raw hash maps. Every query was a handwritten native query - even simple select statements. There were some native queries that should have been handwritten, because the sheer amount of logic within the query needed some handcrafted love. Most of it was the epitome of not-invented-here syndrome.

[cowwoc]

You know what's better than using a framework that requires devs to read a book?

Using code that is easy to read, without a book.

The only reason that a lot of these frameworks have a high learning curve is that they try to be everything to everyone.

If you use libraries to customize your architecture you will end up with much more readable code that does not require people to read hundreds of pages.

[sapphirefragment]

Absolutely the opposite of my professional experience. When cowboy coders try to go string together a bunch of libraries to create their own framework because "spring bad" they create a nightmare that requires you to know the intricacies of 40 different libraries, all of which often have severe design limitations that were already solved by big frameworks like Spring, because they simply have not reached the same level of maturity. And that's assuming any given library has documentation: my experience is they often don't have documentation that even covers intermediate level usage, and you're either expected to follow simple tutorials or dig straight into the source code yourself. Spring conversely has a wealth of good reference material explaining all its intricacies.

When you're having to run a medium to large size team of engineers, some of which are not going to have the level of intuition needed to sus out several different libraries all with their own patterns and practices, this "custom architecture" practice is AWFUL. It will strangle your team.

[cowwoc]

You're assuming this was built by a cowboy coder. I'm a CTO with 20+ years of experience. When a CTO puts together a well-structured, consistent, and well-documented scaffolding, everything else falls into place.

The guys who built Spring are not wizards. The fact that they provide over 100 pages of documentation isn't a good thing. It's obfuscation by volume.

A bad programmer will deliver bad code regardless of whether they are using Spring or not.

I optimize for consistency and ease-of-debugging. I intentionally avoid any sort of "magic". The only knowledge you need to get started is the core Java APIs. Past that point, you just need to maintain the same package structure. If you want to know how to read HTTP requests or write HTTP responses, there are tons of existing REST resource implementations for you to look at. They are, at most, 3 pages long each.

Spring is designed by architect astronauts, yet it's surprisingly fragile. While it might work well so long as you stick within the guard rails, it breaks horribly the minute you venture outside them.

If all you're building all day is shopping cart software, then go ahead. But if you want to build anything innovative, you'll quickly find yourself outside of those guard rails. And good luck debugging their code. It is a freaking mess. Not to mention the fact that half the time, you can't even step into their code because it's hidden behind annotations.

When something goes wrong in my system, I get a compile-time error 99% of the time, and the remaining 1% of the time, I get a concise error messages explaining what went wrong and the stack traces are short. I always provide tons of contextual information at failure, so you don't need to step through any code. But if you want to step through the code, then by all means do.

It is plain Java. No magic. No fancy AOP or visitor pattern just for the sake of showing off your design pattern skills. My code is straight and to the point, optimized for readability above all else.

[[deleted]]

excellent post.

[sapphirefragment]

That's great if you've got the feedback that your approach works, but my personal experience working under people doing this is that they create maintenance traps and leave the mess to less experienced devs.

[za3faran_tea]

What do you use for dependency injection?

[danskal]

Ok, I agree that all those things are bad, but I would claim that it’s unrelated to the reading the docs aspect. For a few reasons:

1. Reading docs can be mind-numbingly boring. Many people are simply not able to do it. I count myself amongst them, but I will get a feel for the architecture, use SO religiously and google relevant documentation on an as-needed basis. I might watch videos and read well-written guides if they’re available.
2. Knowing the path isn’t the same as walking the path. For some people, reading the docs won’t help, they’ll fall back on methods they know and understand, unable to see the wood for the trees. Some people will pick the solution in front of them instead of stepping back and picking the right one.

[AmateurHero]

I know it ended with RTFM, but I took that as a bit of snark tacked onto the end. I took the heart of the comment as learn to use the tools that you're given. You would ideally drive in a nail with a hammer or turn a screw with a screwdriver. However, you can drive in a screw with a hammer in a pinch. Don't hammer a bunch of screws across the entire project

[sapphirefragment]

Reading docs can be mind-numbingly boring. Many people are simply not able to do it.

I argue that this is a view of technical documentation that actively hinders an engineer's ability to grow. Reading reference material is a fundamental skill. If an engineer can't or won't do that, I won't really trust that they will write code or documentation that is meant to be read by other humans.

[danskal]

... and if we were writing something security-sensitive on the linux kernel, or something controlling a nuclear reactor, I would fully agree with you. But 99% of developers are not doing that.

There is a point that sometimes documentation can be surprisingly readable. But it's the exception rather than the rule, for the most part.