Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of Simple Architectures (2022)

danluu.com

Post reply on HN
Print view View original

261–270 of 447 posts

Re: In Defense of Simple Architectures (2022)

#261

Post by HeyLaughingBoy »

zer00eyz wrote: post #10

Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…

It's a common behavior. When I started my last job as the software lead at a small company, I was warned that one of the senior engineers on my team was easily distracted by shiny things. They were not wrong. The dude was smart and effective, but I had to spend way too much time keeping him on task.

Re: In Defense of Simple Architectures (2022)

#262

Post by HeyLaughingBoy »

zer00eyz wrote: post #10

Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…

> I have seen projects get done just to pad a PM or developers resume

This reminds me of the time that I complained that a sensor on the machine we were developing was way too complicated and that there were far simpler ways to accomplish the same thing.

Someone with more history on the project explained. The engineer who designed that sensor expected, and received, a patent for his work. The company was quite generous with patent royalties and no one's getting a patent for an off the shelf float switch!

Re: In Defense of Simple Architectures (2022)

#263

Post by manicennui »

scient wrote: post #66
from-nibly wrote: post #51

This is what I tell engineers. Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance. And an engineering coordination strategy. Theoretically If you have a monolith that can be scaled horizontally there isn't any difference between having 10 replicas of your monolith and having 5 replicas of two microservices with the same codebase. UNLESS you are trying to undersc…

Services, or even microservices, are more of a strategy to allow teams to scale than services or products to scale. I think thats one of the biggest misconceptions for engineers. On the other end you have the monorepo crew, who are doing it for the same reasons. On your note about resiliency and scale - its always a waste of money until shit hits the fan. Then you really pay for it.

Except that most people build microservices in a way that ignores the reality of cloud providers and the fact that they are building (more) distributed systems, and often end up with lower resiliency.

Re: In Defense of Simple Architectures (2022)

#264

Post by naasking »

mjr00 wrote: post #236
naasking wrote: post #234

Earlier quoted context omitted.

Upgrading the platform also happens at least 10x less frequently, so that math doesn't necessarily work out in your favour though.

It's much easier to make smaller scope changes at higher frequency than it is to make large changes at lower frequency. This is the entire reason the software industry adopted CI/CD

I'm not sure that's measuring what you think. The CI pipeline is an incentive for a good test suite, and with a good test suite the frequency and scope of changes matters a lot less.

CI/CD is also an incentive to keep domain-level scope changes small (scope creep tends to be a problem in software development) in order to minimize disruptions to the pipeline.

These are all somewhat different problems than upgrading the platform you're running, which the test suite itself should cover.

Re: In Defense of Simple Architectures (2022)

#265

Post by manicennui »

jakey_bakey wrote: post #196
from-nibly wrote: post #51

This is what I tell engineers. Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance. And an engineering coordination strategy. Theoretically If you have a monolith that can be scaled horizontally there isn't any difference between having 10 replicas of your monolith and having 5 replicas of two microservices with the same codebase. UNLESS you are trying to undersc…

Surely one could split a shared monolith into many internal libraries and modules, facilitating ownership?

It's crazy to me how opposed to building libraries everyone seems these days. We use a fuckton of libraries, but the smallest division of software we'll build is a service.

Re: In Defense of Simple Architectures (2022)

#266

Post by Swizec »

ryandrake wrote: post #255
JAlexoid wrote: post #193

Earlier quoted context omitted.

Exactly. People forget that the final and most important decision for hiring will be at a less technical and much more bean-counting level. That's the reason why CS graduates with only bells and whistles in their CV have hard times getting a relevant position - glitter over your resume doesn't deliver value at all.

> That's the reason why CS graduates with only bells and whistles in their CV have hard times getting a relevant position - glitter over your resume doesn't deliver value at all. If this is true, why does everyone still think that filling up their Technology Bingo card will get them their next job, rather than delivering business value?

> why does everyone still think that filling up their Technology Bingo card will get them their next job

It does for entry and mid level jobs. When you do this you’re advertising that that’s what you’re looking for – a grunt level job.

Unfortunately most job seeking advice out there is for people new to the industry. Because there’s more of them.

Think about it this way: Would you trust a CEO whose resume lists word, excel, powerpoint, and google docs under skills? Probably not, but you sure would expect a ceo knows how to use those.

Re: In Defense of Simple Architectures (2022)

#267

Post by jokoon »

Gall's law:

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."

It's quite funny how unknown this quote is. Imagine all the developers that would be out of work if we had simpler systems. It's hard to admit, but developers get more jobs when their work is complicated, it's the hostage taker syndrome.

Software as a thing, is pretty recent, it's important to remember it has a large Silicon Valley influence, and software quality is just unregulated because of freedom of speech warriors.

The software we have today, is just the combination of good government funding and marketing maniacs.

Re: In Defense of Simple Architectures (2022)

#268

Post by fHr »

01HNNWZ0MV43FF wrote: post #139
codingdave wrote: post #108

Earlier quoted context omitted.

Because your work is then stable. Easy to maintain, not getting paged for customer problems. Which leaves you the time to do more work that will be interesting and beneficial.

No it doesn't. If your work is easy, the scale gets ratcheted up until it's nearly impossible. That's why web devs have so much trouble with the seemingly-simple task of parsing and producing text

True, exactly witnessed this a dozen times.

Re: In Defense of Simple Architectures (2022)

#269

Post by philipbjorge »

lelanthran wrote: post #62
2d8a875f-39a2-4 wrote: post #39

I agree with the general sentiment that simple architectures are better and monoliths are mostly fine. But. I've dealt with way too many teams whose shit is falling over due to synchronous IO even at laughably low volumes. Don't do that if you can avoid it. "Subtle data-integrity bugs" are not something we should be discussing in a system of financial record. Avoiding them should have been designed in from the start.

> shit is falling over due to synchronous IO even at laughably low volumes. Like? I ask because even synchronous IO let's you serve millions of requests per month on a cheap VPS. That's enough in the b2b space to keep a company of 1000 employees in business.

Recently I worked on a project that was using synchronous IO in an async framework -- That tanked performance immediately and effectively meant that the application could service one request at a time while subsequent requests started queuing.

(Agreed that synchronous IO can serve hundreds of requests per second with the right threading model)

Re: In Defense of Simple Architectures (2022)

#270

Post by groestl »

isoprophlex wrote: post #242
rizzom5000 wrote: post #226

Earlier quoted context omitted.

> no intellectual challenge I tend to think that cargo cult programming and resume-driven development are the intellectual path of least resistance. Perhaps it's analogous to, "I'd rather rewrite this than understand how it works", because that requires less intellectual effort. Quality engineering is not achieved by the intellectually lazy, from what I've seen.

You're not wrong, but when you're inheriting a convoluted 50 file React shitfest that could have been a single HTML page and 20 lines of javascript... what are you going to do? Invest time in understanding that, or radically simplify in 20% of the time it takes to grok what you get thrown at you?

No, a single HTML page and 20 lines of Javascript is clear cut. But there's a _lot_ of instances where it's not that way, and still rewrites are being proposed.
Post reply on HN