Comment by jfaucett | Hacker News Reader

Comment by jfaucett | Hacker News Reader

Summary:

1. The term "Monolith" has a bad rep.

2. "Majestic Monolith" means eliminating needless abstraction and avoiding distributing your system (unless unavoidable)

3. The term also means writing "beautiful, understandable, and succinct code ... that makes us smile when we write it ... and later have to extend or patch it".

4. Everyone has to understand all parts in the "majestic monolith".

5. The "Majestic Monolith" puts pressure on / incentivizes programmers to keep the code-base clean.

6. Most programmers will rise to the occasion.

I think most programmers would agree with the meanings/goals ascribed in 2-3 (possibly also 4, if 4 is understood as deeply understanding the structure of your software product), as just generally good rules for building software in general.

1, 5, and 6 seem highly subjective to me. I tend to think if you're building anything stringently according to 2-3 you'd probably be fine and could call that method whatever you wanted to.

There were some interesting ideas in here, regardless of whether or not the argument for the majestic monolith succeeded.

I think he started with this (good) principle:

  >an integrated system that collapses as many unnecessary
  >conceptual models as possible. Eliminates as much 
  >needless abstraction as you can swing a hammer at.

And then went on to conclude that the 'monolith' is the only way to do it.

There are ways to eliminate needless abstraction while still keeping proper separation of concerns

Separation of concerns is not dependent on having a network layers between your function calls though. You can have a well structured monolith with different inner well separated parts. It's just easier to cheat in code than over the network.

Ultimately separation of concerns is an organizational and social problem, not a technical problem.

Technical enforcement beats "best practices" every time.

(But you can enforce separation of concerns through a language that lets you do that rather than needing a network connection)

>Technical enforcement beats "best practices" every time.

Not in my experience. People will find a way to beat even the best "technical enforcement" every time. Not necessarily hack it -- just work around it to move the problem elsewhere.

There's no way to stop people working around things. But an automated warning is far more reliable than constant vigilance on the part of the programmer.

Even more reliable is to keep your programs small :)

Not my experience.

While 1, 5, and 6 seem highly subjective, 1 certainly matches my experience talking architecture over the years and failing to do 5 certainly has lead to the death of more than one project that I've been involved in.

6 is only true if you've hired the right people :-)

6 is only true if you can afford to hire good people.

If you can't afford/attract the good people, they will learn in your business e.g. make failure which you have to pay for.

I think everyone makes this failure early on in her/his career and it's only avoidable if senior developers can teach newbies in a way that makes sense and is understandable.

In the end, most people come to the conclusion that programming languages are less important for success but bad habits and complexity can kill everything. Even with frameworks who most of us tend to rate as "easy to learn" I've seen people completely messing it up. There is no language and/or framework that prevents people from mistakes AND allow them to learn/work productivly.

There is no holy grail. It's part of our job to justify technology problems and the usage of (new/old) solutions to fix the problems. Ignoring the past and/or ignoring the future (= trend) is a mistake. Learn to question your tech things regularly without questioning yourself.

Sure, it's easier for one to "ride the wave" of a hype. Container everthing, microservice everything. Our tech landscape grows complexity even faster than a couple of years ago. Somehow many people love complexity because they don't enjoy writing "stupid business software" and want to be some mad architect that rewrites everything in his/her favorite niche language with 10 new layers of indirection just because…

>Somehow many people love complexity because they don't enjoy writing "stupid business software" and want to be some mad architect that rewrites everything in his/her favorite niche language with 10 new layers of indirection just because…

These are the worst type of programmers. Complexity for the sake of complexity. They will replace a ten line Python script with a Python "app" made up of multiple classes. Each class containing its own generator implementation because using loops or recursion is for noobs...

If you have bad programmers who are pushing hard on a microservices architecture, you're probably in for more trouble than bad programmers maintaining a monolith. Big, complex monoliths can be tough to work with, but probably overall easier than poorly-designed microservices.

...Or if you can inspire them with your mission. For example, Watsi is a non-profit, yet the caliber of their engineering talent is incredibly high according to pg. I can't find that quote, but here's another quote along the same lines, from the co-founder of triplebyte: https://twitter.com/Harjeet/status/684478156716150784

1, 5, and 6 all seem quite objective, although whether they are accurate is debatable. They aren't given much empirical support here.

Reply on news.ycombinator.com