Hacker News Reader

Comment by sdevonoes | Hacker News Reader

I would add: "Follow the rules no matter what"

I've seen people reading about CQRS, Clean Code, Hexagonal Architecture, Event Bus, all these "good practices" published by celebrities... and after some time these people believe "they are right" because they know these patterns and because they apply them every time code needs to be written. It's difficult to reason with them; the conversation usually goes this way:

- Joe: We should use Hexagonal Architecture in our new system because Alistair Cockburn knows what's best

- Me: I think we don't need it? Past experience in other projects of ours says we can handle this new system without HA

- Joe: I don't think you know better than Alistair Cockburn, so let's stick with HA

View on HN

I'm not a fan of dogma, in general. The whole "My only tool is a hammer" deal.

Many architectures and techniques (CI/D, TDD Unit Testing, etc.) are based on large projects, with multiple developers, being reassigned and rotated frequently. They often can be applied to smaller projects, but their effectiveness is not always on par with large projects.

I tend to write alone. That means that my scope is, out of necessity, much smaller than many people enjoy, but it also means that a lot of infrastructure overhead is actually a severe problem.

The advantage of writing alone, is a flexibility that many teams could only dream of, and having a lot of team overhead management practices and structure in place, absolutely kills flexibility.

Oh, man, I've seen the damages this kind of thinking does.

The Terse vs Verbose code debate is important and all, but honestly architecture is the thing that can make or break a project.

Picking the wrong architecture for the job is the kinda thing that delays features, brings more bugs to the table and will make the exact same people ask for a rewrite down the line.

I once worked on a company that was dominated by such types. They made terrible architectural decisions out of cargo-cult and it took two backend rewrites in a row to get things half-right, but they still ended up with a mongrel codebase with several mixed complex patterns.

In your example, your real-life experience matters 100x more than Joe's opinion of whatever architecture he wants to use.

They already know "the answer" before hearing the problem and it's the same answer every time.

Sometimes it's medical quackery, other times it's economic policy orthodoxy or religious moralism and sometimes it's software stuff

It's fundamentalism. I've gotta go back to working on that book. It's all the same shit and enters and exits people's heads through the same emotional and environmental triggers

What book?

I have found that, especially in the cloud with the many SAAS, IAAS, and PAAS offerings there, people end up implementing some kind of poorly thought out CQRS/Event Bus architecture because these offerings naturally lead that way. Attempting to bring some order to it by actually applying these patterns in a structured way is met by something like "that seems complicated" or "we'll never need it" or "why would we keep a log of all of our events"?

If you're doing distributed cloud event based systems these are sane ways to go about it. I contend though that usually you can get away with a series of big fat SQL databases until you're well into the billion in revenue a year club.

Your co-workers argument was an appeal to authority. That's not sufficient. Your argument is a straw-man. That's also not sufficient.

The set of patterns that you mention are a different paradigm from the typical OOP-based paradigms. They come from people who are looking at code and seeking composability. As they come at it from a different perspective, when an OOP-programmer comes at the patterns they will cross a "weirdness budget" limit and superficially disregard it.

Any architecture - in a Turing complete language - can solve any problem. All programmers should be seeking to keep complexity to a minimum, while also being well understood. Complexity is made up of two elements, essential complexity that all problems have, and accidental complexity. Accidental complexity can arise out of all sorts of ways, and skill of the programmer, maturity of the architecture, and many others.

Switching to a different architecture that you are not familiar with will cause accidental complexity. Switching to an architecture that has not been well tested will cause accidental complexity.

I believe that CQRS, Clean Code, Hexagonal Architecture, Event Bus are all patterns that will eventually be proven to be correct for most people in most situations, but that the tooling for all of them is not yet there. You should evaluate the patterns for yourself and test them out and find what you can take away that works today. I do not currently use all of them myself even though I believe in their long-term suitability. I do the same for OOP frameworks. The only way to know anything is by trying it yourself and getting to know it.

Yeah, this drives me crazy. I've had people in the past suggest supporting legacy apis on our project that has exactly one consumer (whose code we can directly update in the same repo), or adding wrapper functions all over the place for "layers" in an app that's like maybe 10,000 lines of code. These things are perfectly fine in the context they're designed for, but people love their shiny new hammers.

Agreed! If you can't explain WHY the design decision is the right decision, you haven't thought hard enough.

If I ever hear folks name-dropping, that line of discussion ends and we need to reign it back in to the real "choices and trade-offs" discussion that will get us a real solution, not some abstract opinions.

Everything is gold plating until it isn’t. So do you bet on the project going big and deep or not ?

Reply on news.ycombinator.com