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

Learning Software Architecture

matklad.github.io

Post reply on HN
Print view View original

111–120 of 133 posts

Re: Learning Software Architecture

#111

Post by rafael-lua »

embedding-shape wrote: post #75
CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Missing the single most important thing, that people seemingly are purposefully trying to avoid nowadays for some reason: - It depends No solution I've come across, is a solution for everything, everywhere. It's almost always context dependent, and something that is right in one place, can be utterly wrong in another, and there is no universal truths regarding design and architecture. The more flexible you can be wit…

To be honest, "It depends" is also exhausting. I have some defaults that I push until the breaking point, though I apply this more often on personal projects. DDD is an exception, as even professionally I will vomit DDD concepts as solutions for literally anything. "This could have been an aggregate", I will say like a mantra.

Re: Learning Software Architecture

#112

Post by rafael-lua »

bfivyvysj wrote: post #86
CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Great list but I dunno about coupling being evil, it is literally the only place anything important happens.

Coupling is evil, as it is the main root of all the nastiest problems I have found in many projects I worked on. It is the main cause of "throw it all away and start greenfield" in my experience. I mean, it is important and needs to be done right, but it is yet evil.

Re: Learning Software Architecture

#113

Post by deepsun »

The best way to learn architecture is to:

1. Maintain a large enough project. Not create, but support.

2. Do it for at least couple or few projects.

If project is too small, any architecture works fine. "Large" can be in terms of lines of code, but better in terms of people who ever worked on it, or even better -- teams.

At least two different projects is to have something to compare. I've seen people stuck for decades on one project and not knowing any modern ways to solve a problem.

But often the architects who get promoted because they created, not maintained a project. Especially visible in Google, as you don't get promoted for maintaining anything, only for shipping something new (and better jumping off as soon as possible afterwards).

Counterintuitively, people in the best position to be architects are actually side contractors from head shops, who get invited to maintain an existing project no one from a company is willing to (as they all jumped off where promotions go). First, they have to maintain an architecture, and second they did it on several projects, so can compare. The downside though, is if they bill by the hour, the tend to over-complicate architecture to bill more hours.

Re: Learning Software Architecture

#114

Post by rafael-lua »

electrosphere wrote: post #52
CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Good list! One addition? * start with a modular monolith

This one has yet to enter my head. I read Martin Fowler's related article* a few times, and it is sound... But I still can't see microservices being so "complex" to be so avoided early on. Especially in 2026, with the level of IaC and pipelines we have. I might be naïve, but I just don't get it.

(*) https://martinfowler.com/bliki/MonolithFirst.html

Re: Learning Software Architecture

#115

Post by abustamam »

AnimalMuppet wrote: post #63
laszlojamf wrote: post #39

Earlier quoted context omitted.

I'd add - data migrations are inevitable and should be planned for (corollary of versioning) - planning is good, sometimes you just have to try things out - everything costs money. Designing without costs in mind will force hard choices down the line

I'll add another to that: - Code lives longer than you expect. You forget sooner than you expect. Make a readme/architecture overview/theory of operation document. Put more in it than you think is needed. Check it in with the code.

If I had a dollar for every time "throwaway code" became foundational code...

Re: Learning Software Architecture

#116

Post by abustamam »

embedding-shape wrote: post #75
CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Missing the single most important thing, that people seemingly are purposefully trying to avoid nowadays for some reason: - It depends No solution I've come across, is a solution for everything, everywhere. It's almost always context dependent, and something that is right in one place, can be utterly wrong in another, and there is no universal truths regarding design and architecture. The more flexible you can be wit…

I found I did pretty well in the interview stage whenever I'd start an answer with "it depends"

Of course, I'd have to back that up with assumptions and goals and such, but I think that's the point. X technology is great at Y but not so great at Z, so if you want to optimize for Z maybe don't use X.

Re: Learning Software Architecture

#117

Post by keithnz »

CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

I don't actually think this has much to do with software architecture. Except maybe the "Isolate parts of your system..."

In fact the article itself didn't really seem to be too coherent on software architecture. I think the 4+1 view of software architecture is a good conceptual way to think about things (minus all the UML). It's not a complete picture but it addresses the bigger picture. The book series Pattern-Oriented Software Architecture is pretty good and outlines a number of architectures people tend to land on. One stage Grady Booch was working on a handbook of software architecture, but seems to be kind of dead ish, but he did have a mailing list where he'd go to companies or look at large open source projects and look document big system architectures (and some smaller scale), not sure where you can see this anymore. All of these things are worth diving into if you want to learn about software architecture. You can see these architectures are built for different focuses, things like scale, safety, performance, interoperability, failsafe, etc. i.e. there are very specific goals of an architecture with very real tradeoffs.

Re: Learning Software Architecture

#118

Post by topaz0 »

munk-a wrote: post #101
kachnuv_ocasek wrote: post #88

Earlier quoted context omitted.

What exactly do you mean by “make state explicit”?

Minimizing side effects (e.g. functional programming) is a good habit in general. But when we're talking at the scale of a company's entire software solution state is the enemy of everything that is good. You never want to work on a platform with 500k lines of code any of which could mutate variable state at will and the more you can isolate or simplify state usage the better your life will be.

It's also the enemy of evil things your company does.

Re: Learning Software Architecture

#119

Post by dirtbag__dad »

miki123211 wrote: post #96
CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

I don't agree with all of these, but I'll add a couple of my own: - The ultimate goal of software is to solve the immediate problem at hand. The secondary goal of software is to solve likely future problems with as little work as possible. Any bad design which is better on those goals than a good design is actually a good design. - Make your interfaces easy to use correctly and hard to misuse. Think of how people unf…

> The ultimate goal of software is to solve the immediate problem at hand. The secondary goal of software is to solve likely future problems with as little work as possible.

Not really. Today I learned of a story where a vibe coding PM deployed a vercel app, which was in its entirety a single react component that serves a banner, that was embedded via an iframe into an entirely separate web app, whose repo they have full access to, because they needed to get a modal component out the door, but were blocked because they “couldn’t upload the image to s3.” (They could just use the public/ or assets/ directory and have the cdn pick it up, too.)

People do the most insane things when they are tight on time and don’t have the intuition to do a bit of research up front. If you ask them, they’re solving the immediate problem at hand. If you ask anyone else who interacts with their work, they’re disrupting our days/weeks/months/years when we have to step through systems that don’t know any better.

If you have the muscle to plan ahead, even a little bit, which is usually just following the same pattern over and over again, then you are fine.

In this world you are still optimizing for the now problem but you have also solved, to some and ideally a better degree, some future problems for free

Re: Learning Software Architecture

#120

Post by dirtbag__dad »

CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Good architecture is not about the patterns you pick. It’s about having a team dev cohesively on any pattern(s)

- programmatically enforce your style with in-house linters and scaffolders. Be highly opinionated

- if you # ignore anything, leave a comment explaining why

- use bdd so your cases are human readable and must update with the code (unlike a stale comment)

- follow the same pattern in all your services (I love hexagonal design for backend). If you break from the design have a good reason for it

- COMPOSE your code. It’s almost always the case that two endpoints or jobs or whatever happen to have a few things in common, but differ wildly. Don’t get DRY, just import those things in each spot and don’t entangle them with each other, it’s too confusing

- scope your interfaces tightly. No optional params unless the domain is actually optional. Make separate jobs or endpoints for different configs. I can’t figure out wtf all your configs were from 4 years ago and neither can you

- code is default testable with DI/DIP

- always run tests running real infra like testcontainers - cement ci/cd as your guardian. Employ every linter you can.

- hammer workarounds with comments in the code

- break all systems into small problems and nothing is challenging technically (though the domain might be!)

- work with less people on your code. It’s easier to stay aligned and follow the same patterns

- don’t expect anyone to figure it out. You need to champion your changes. Do code reviews, hold their hand, show them the way

- clear out mundane items like installfests, local auth, server reloads. Slow dev pisses people off

- finally, and most important, employ an org policy for review. Don’t let shit fall through the cracks unknowingly. It compounds. You have skills now as a quick and dirty to eval and enforce. Use them!

Post reply on HN