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

181–190 of 447 posts

Re: In Defense of Simple Architectures (2022)

#181

Post by fatnoah »

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…

> When cloud was the hot new thing the company that I worked with launched a replatform on AWS. It gave us the ability to get through the initial scaling and sizing with ease. We left right away, because even then the costs did not make sense.

Cases like this always fascinate me. I've led a "move from Data Center to AWS" effort twice, and both times it was at > 50% cost savings. However, I think both were probably small infra footprints compared to many cases like many others.

Re: In Defense of Simple Architectures (2022)

#182

Post by jerf »

throwaway2037 wrote: post #110
jerf wrote: post #80

Earlier quoted context omitted.

Python has good library support, but sometimes it seems like Python advocates speak as if it is somehow uniquely equipped with libraries that nobody else has. There's a dozen other languages with well-established libraries for everything mrkeen mentioned, as well as healthy ecosystems that can be completely expected to support everything else a financial app may reasonable expect to need. Python wasn't a bad choice b…

> But Python's disadvantages can be pretty significant. "Dynamic typing" and "deals with money" is a combination that would make me pretty nervous. YMMV. This is an interesting comment. I do not disagree. In your opinion, if not Python, then what languages would be acceptable to you?

Starting today: Go, C#, Rust, possibly TypeScript (not my personal choice but probably acceptable), Java (which despite being poorly done in a lot of places does have the tooling necessary for this if used by decent programmers). C++ with a super-strong static analysis tool like Coverity used from day one. (I consider C or C++ plus something like Coverity to be essentially a different language than using just a C or C++ compiler.)

And that's sticking to reasonably mainstream languages. F#, D, Scala, Haskell, Lisp with strong typing around the money parts (or Clojure), probably a couple of others as well. These have problems with having smaller communities and being harder to hire for, but I'd bet that pretty much all of them still have well-supported libraries for nearly everything a financial company would need to do. (And that you could expect general open source libraries for. Super-specific internal financial protocols may not have libraries in general, or may only be in Java, etc.)

Also I make no exclusivity claims that these are the only appropriate languages, so if you've got a favorite statically-typed language feel free to just mentally edit it in without asking me how I could possibly miss it. (I'm not familiar enough with the Objective-C family to have informed opinions about it, for instance.)

Dynamically-typed languages with progressive typing used rigidly around the money might be OK, but progressive typing makes me nervous and really seems like a bodge in a lot of places. Reading people's experiences with them, even when the person writing the experience is nominally positive on the experience, has not generally impressed me.

Re: In Defense of Simple Architectures (2022)

#183

Post by emseetech »

bluGill wrote: post #169
emseetech wrote: post #133

Arguing for simple architectures is hard. Everyone wants to argue that yes, they ARE going to need it. Maybe not now but someday, therefore they should have it. Always reminds me of this scene from Arrested Development. https://www.youtube.com/watch?v=VVtOkX-gUxU&t=132s

I've been in the situation where someone argued we didn't need something so go simple - turns out they were wrong (isn't hindsight nice) but now the system was based around this incorrect assumption and really hard to rework into the thing we needed. This is why architecture is hard. It is about making the decisions in advance that you will regret getting wrong.

> now the system was based around this incorrect assumption

How big of a userbase and what made it particularly difficult to refactor?

Re: In Defense of Simple Architectures (2022)

#184

Post by bjornsing »

palata wrote: post #99

I believe it is as easy to over-engineer as it is to under-engineer. Architecture is the art of doing "just enough"; it must be as simple as possible, but as complex as necessary. But that is hard to do, and it takes experience. And one thing that does not describe the IT industry well is "experience": don't most software developers have less than 5 years experience? You can read all the books you want and pass all t…

> Architecture is the art of doing "just enough"; it must be as simple as possible, but as complex as necessary.

Or as Albert Einstein phrased it: “Everything should be made as simple as possible, but not simpler!”

Re: In Defense of Simple Architectures (2022)

#185

Post by vendiddy »

I like to treat simplicity as an ingrained attitude.

When hiring someone, I love to see if they are visibly annoyed when something is over-engineered. Or when a user interface is too complex.

If they have strong emotional reaction, it's a good cultural fit :)

The inverse is true too. If someone "gets off" to complexity, I view it a red flag.

Re: In Defense of Simple Architectures (2022)

#186

Post by armanboyaci »

hiAndrewQuinn wrote: post #172

"Simple" is an interesting term. I've always found it to be very relative to what someone's actual experiences and knowledge bases are. For example, virtual machines are something I and probably most other people consider "simple". They're pretty much just little computers. For the most part, I can just work with VMs the same way I would work with computers. No sweat. My DevOps pedigree, however, also means I conside…

Very good and important observation. In his talk "Simple made easy" [1] Rich Hickey defines simple as opposite of complex and easy as opposite of hard.

The easiness is relative (as you described) and depends on the things you are familiar with. For example, Docker containers and k8s stuff is easy (for you), and GraphQL is hard (for you).

The simplicity should be assessed (somehow) more objectively.

[1] https://www.youtube.com/watch?v=SxdOUGdseq4

Re: In Defense of Simple Architectures (2022)

#188

Post by palata »

geodel wrote: post #149
palata wrote: post #99

I believe it is as easy to over-engineer as it is to under-engineer. Architecture is the art of doing "just enough"; it must be as simple as possible, but as complex as necessary. But that is hard to do, and it takes experience. And one thing that does not describe the IT industry well is "experience": don't most software developers have less than 5 years experience? You can read all the books you want and pass all t…

Well I have seen lot of people with 20 years of experience which is actually 2 year experience repeated 10 times.

That's not what I am saying. I am saying that you cannot make 20 years of experience in 2 years.

You are saying that some people with 20 years of experience are worse architects than others.

Re: In Defense of Simple Architectures (2022)

#189

Post by treflop »

bluGill wrote: post #162
treflop wrote: post #116

The problem is that most people have never actually built something in all the architectures they are considering. They just read blog posts of what to do. As an analogy, I’ve manufactured a lot of stuff out of wood, concrete, plastic (3D printed) and increasingly more metal. When I need a jig, I know what each material will be like and what I will be getting out of it.

If I tell you that clay is better for your next project then you don't know enough. Am I right or wrong - should you invest a lot of money into clay equipment, and time into learning to use clay? You need to make a decision based on what others say about the advantages of clay - maybe clay isn't better, maybe it is better but not by enough to be worth learning. If this is just for fun maybe you say you want to learn…

Well if my day job is building stuff and it’s the reason I picked this career and it seems companies pay $$$$, give great benefits, and lets me take 2-4+ week vacations wherever I want if I’m good at it, and going to work is great because everyone gives you the fun problems knowing very well you know your shit…

Yes, it's worth learning a little about clay. Maybe I'll even enjoy it.

(And I know you’re trying to make an example, but I have already looked into clay a bunch of times. Clay just doesn't have the material properties that my projects tend to need. It'd be like learning COBOL expecting to build front-end apps.)

Re: In Defense of Simple Architectures (2022)

#190

Post by neonsunset »

throwaway2037 wrote: post #113
xnorswap wrote: post #79

Earlier quoted context omitted.

One answer to your question is C# / .Net. Combines excellent concurrency primitives, very good performance, and a deep reservoir of packages and libraries. Of course it's almost never worth switching languages for an existing product, you just get left with a mess of half-old and half-new tooling and invariably get left having to support both languages.

Real question: From your specific comment, are there any advantages of C# vs Java here?

Way worse building, packaging and dependency management experience. Worse ORM experience. Making simple single-file executables requires way more ceremony versus 1-3 toggles, sometimes not even possible at all. A lot of small and large papercuts in places where Java simply does worse, more expensive interop and reaching performance ceiling is way more difficult due to lack of low-level primitives. Terser syntax especially the functional parts of it and more lightweight tooling in the SDK, a lot of ceremony around dealing with just making sure you dev environment works does not exist in .NET (as long as you don’t start putting everything into custom paths). Building a complete product is dotnet publish, running an application is dotnet run, which requires more setup and scripting with Java.
Post reply on HN