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

411–420 of 447 posts

Re: In Defense of Simple Architectures (2022)

#411

Post by loup-vaillant »

Swizec wrote: post #391
loup-vaillant wrote: post #379

Earlier quoted context omitted.

The reason I speak of "neurotypical bullshit" is because people around me have several times suspected I'm on the spectrum, and I noticed I have a hard time dealing with subtle social cues. One manifestation of this is when someone asks me something with a straight face, I tend to assume they actually want what they asked for. When someone asks them feedback so they can improve, I tend to concentrate on what could ha…

Here's the thing: You're right. And also you're not. Sometimes, often, feedback is about timing. The time to talk about how better to architect a thing is when it's being architected, not 2 months later. Instead of "This is crap" try "Hey I know this works for now, but there's room for improvement here. Next time we're talking about a system like this can I help with design? I have a few ideas what we might improve".…

I wish I could have that good timing, but I'm rarely hired early enough.

Re: In Defense of Simple Architectures (2022)

#412

Post by loup-vaillant »

yen223 wrote: post #394
loup-vaillant wrote: post #376

Earlier quoted context omitted.

I rarely got to know the actual deployment scale of anything I've done. Let's make a list: Ground software for an observation satellite. My internship was about implementing a dead simple neural "network" (2 hidden layers, no feedback), everything was specified from up top, we didn't even get to touch the learning algorithms. Impact? I guess a big flat zero, since all the differentiators was in the learning parameter…

If I could offer one piece of unsolicited advice: in whatever you do next, make it a point to understand a) how the business is doing and b) what your impact to the business will be. Make it a point to gather numbers like e.g. revenue figures, growth rates, costs, usage metrics. It is true that us underlings aren't usually handed these numbers, but you might be surprised by how easy it is to get them once you start l…

(Thanks for the compliment!)

I should be able to try this the next few weeks (new gig). But again, I'll be working on a prototype where such projections have already been made, the plan have already been laid out, and I'll mostly have to follow orders with relatively little wiggle room (they also expect me to hit the ground running). My only expected impact there is whether the stuff gets done on time or not. And assuming it is, the main company will throw the prototype away and rewrite everything anyway (at least they're supposed to).

Re: In Defense of Simple Architectures (2022)

#413

Post by loup-vaillant »

aprdm wrote: post #395
loup-vaillant wrote: post #378

Earlier quoted context omitted.

It's how most people had me work. It's how most of my colleagues had to work too. Just doing what my manager tells me to work on is what is considered normal and expected in… 8 of the 10 or so places I've worked at. The empowerment you speak of is but a faint dream in my town.

Interesting. That's different from companies I've worked at, where the sw developer usually asks for clarifications and can fight back if they have something else that they feel should be worked on that has a bigger ROI for the company. Companies I've worked at recently have been much more bottom up than top down

We can definitely ask for clarification. But fighting back is a grounds for being moved up the ax list. One workaround is trying stuff for free and present the results. Free labour for the employer, yay!

Re: In Defense of Simple Architectures (2022)

#414

Post by Fanmade »

default-kramer wrote: post #398
lll-o-lll wrote: post #349

Earlier quoted context omitted.

> I've never really understood why you couldn't just break up your monolith into modules You can! We used to do this! Some of us still do this! It is, however, much more difficult. Not difficult technically, but difficult because it requires discipline. The organisations I’ve worked at that have achieved this always had some form of dictator who could enforce the separation. Look at the work done by John Lakos (and v…

> easy way to enforce modularity and does not require the strict discipline required in a monolith In my experience, microservices require more discipline than monoliths. If you do a microservice architecture without discipline you end up with the "distributed monolith" pattern and now you have the worst of both worlds.

Yes, I completely agree. If your team doesn't have the skills to use a proper architecture within a monolith, letting them loose on a distributed system will make things a lot worse. I've seen that happen multiple times.

Re: In Defense of Simple Architectures (2022)

#415

Post by Fanmade »

dalyons wrote: post #384
lll-o-lll wrote: post #349

Earlier quoted context omitted.

> I've never really understood why you couldn't just break up your monolith into modules You can! We used to do this! Some of us still do this! It is, however, much more difficult. Not difficult technically, but difficult because it requires discipline. The organisations I’ve worked at that have achieved this always had some form of dictator who could enforce the separation. Look at the work done by John Lakos (and v…

i agree that its possible. From what i've seen its probably harder though than just doing services. You are fighting against human nature, organizational incentives, etc. As soon as the discipline of the developers, or vigilance of the dictator lapses, it degenerates.

It is really hard to read this for me. How can anyone think that it is harder to write a proper monolith than implementing a distributed architecture?

If you just follow the SOLID principles, you're already 90% there. If your team doesn't have the knowledge (it's not just "discipline", because every proper developer should know that they will make it harder for everyone including themselves if they don't follow proper architecture) to write structured code, letting them loose on a distributed system will make things much, much worse.

Re: In Defense of Simple Architectures (2022)

#416

Post by wg0 »

Tainnor wrote: post #341
wg0 wrote: post #207

Earlier quoted context omitted.

You can scale those things with libraries also. The very browser that you're using to read this comment is an example of it. FreeType, Hurfbaz, Pango, Cairo, Uniscribe, GDI, zlib this that and a deep deep dependency tree built by people who never have talked to each other directly other than the documentation of their libraries - works perfectly well. I assure you 98% of the companies have simpler and shallower code…

> Hurfbaz This made me chuckle. :) It's HarfBuzz. Yours sounds like a goblin.

I could't recall the correct name but originally, it is in Persian حرف باز and in that باز would be transliterated as Baz.

But yes, you're right.

Re: In Defense of Simple Architectures (2022)

#417

Post by berkes »

dartos wrote: post #407
berkes wrote: post #279

Earlier quoted context omitted.

All of them in the last decade. But I guess we misunderstand each-other. None of them cared that I knew "a lot of stuff that isn't appropriate here". For example, a recent gig, hired me because I'm not just another Rails "expert", but a Rails expert with Typescript experience, who built large CI/CD pipelines with containers and has built complex (is there another way?) AWS infrastructures etc. Sometimes they need som…

I envy that position. Feels like because I didn’t work in go or python at my most recent job, I’m having trouble landing anything. (I have 5 years of golang prior to my most recent job) My experience working in devops doesn’t seem to matter for SE positions either.

I do freelance gigs. And I charge what's "enough" for me, so price may play a role. And so I have several gigs a year. I'm on my third for 2024.

I give talks on meetups and conferences, so my insights are seen.

I prefer to work in start- or scale ups, so there's a real need for some "know it all".

Re: In Defense of Simple Architectures (2022)

#418

Post by jakewins »

notpachet wrote: post #118
quaunaut wrote: post #68

Earlier quoted context omitted.

Why? What inherent advantage do those languages have with financial logic?

Better static analysis, for one.

We have services in Python and C# at $dayjob, and my experience is that Python has mostly left C# behind here - what is something you can express in the C# type system that MyPy cannot statically check?

Conversely, I find myself constrained by C#'s typesystem not having features now widely popular from Rust and Typescript and available in modern Python: const generics / literals, protocols/structural interfaces and matching over algebraic datatypes, to name a few examples.

Re: In Defense of Simple Architectures (2022)

#419

Post by tveita »

eadmund wrote: post #289

I agree with the majority of this with respect to simplicity in general, and only really take issue with this bit, about GraphQL: > • Our various apps (user app, support app, Wave agent app, etc.) can mostly share one API, reducing complexity This could of course be done with a RESTful API. > • Composable query language allows clients to fetch exactly the data they need in a single packet roundtrip without needing to…

> Two approaches which immediately spring to mind are passing desired items as query parameters or passing a template item as a query parameter or request body.

I've implemented this twice, you quickly end up at something resembling GraphQL after a couple of rounds of "iOS needs the the profile picture in two different sizes, dependent on native screen size, and with version 2 of the blurhash"

Might as well use GraphQL and get schemas, libraries for clients and servers and IDE support out of the box at that point. It's no panacea - many of the backend libraries were somewhat low quality last time I checked - but I wouldn't hesitate to use it if I had a somewhat complex main product served by multiple frontends following different UI guidelines.

Re: In Defense of Simple Architectures (2022)

#420

Post by neonsunset »

jakewins wrote: post #418
notpachet wrote: post #118

Earlier quoted context omitted.

Better static analysis, for one.

We have services in Python and C# at $dayjob, and my experience is that Python has mostly left C# behind here - what is something you can express in the C# type system that MyPy cannot statically check? Conversely, I find myself constrained by C#'s typesystem not having features now widely popular from Rust and Typescript and available in modern Python: const generics / literals, protocols/structural interfaces and m…

Was bewildered when reading this message. How come? Python and TypeScript by definition don't have a concept of const generics the way it applies to C++ templates or Rust.

Nor "matching over algebraic datatypes" made any sense - sure sounds slightly below average fancy but comes down to just using C# pattern matching effectively, which the author may have never done. But then it struck me "structural interfaces sure sounds familiar", I go check the pinned repositories in the github profile and it all made sense immediately - the pinned ones are written in Go, which explains the author's woes with confidently navigating something more sophisticated.

Post reply on HN