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

91–100 of 133 posts

Re: Learning Software Architecture

#91

Post by grusgrus »

finnnk wrote: post #29

I'm surprised that it seems no-one has brought up Residuality (see https://www.architecture-weekly.com/p/residuality-theory-a-r... ) which is a very interesting take on architecture (as opposed to design) which aligns with my own experiences. As well as the book ( https://leanpub.com/residuality ) the author has one on the philosophy of architecture ( https://leanpub.com/architectsparadox ).

Wanted to say thanks for posting this. I found the NDC talk interesting and well presented. Will try to read more about it and, as an exercise, try applying it to my own solutions to see what insights I could gain.

Re: Learning Software Architecture

#92

Post by embedding-shape »

RobRivera wrote: post #56
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 wish I could buy you a beer, as this is very validating. I have been building a video game for over a year. But more importantly I have been building a sustainable engine with a distinct data pipeline, resource rendering/management layer fully decoupled, explicit catalogueing of viable state transformation modes, and honestly, most of your list is absolutely applicable. Even tho it is solo, the constraints of my en…

Ah, the infamous "I believe I'm building a video game, but in reality I'm building a video game engine and I don't realize it yet" every game developer goes through at least once, god speed to you :)

Re: Learning Software Architecture

#93

Post by sroerick »

mpweiher wrote: post #8

The recommendations are often very good, for example Ousterhouts A Philosophy of Software Design , but seem to be on software development in general, not actually software architecture in particular. For that, I would recommend the classic texts, such as Software Architecture: Perspectives on an Emerging Discipline (Shaw/Garlan) and really anything you can find by Mary Shaw. Including more recent papers that explore…

What is hexagonal architecture?

Re: Learning Software Architecture

#94

Post by serial_dev »

mwexler wrote: post #44
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…

Can you explain the last one? What types of communications are you suggesting an arch would avoid? Otherwise, a very wise list!

Just one more alternative interpretation… I thought it’s about systems calling into other systems, making everything slower, more complicated and brittle…

But maybe it’s about discussing an issue with 10 other people from different teams when it’s not necessary.

But we will never now. I guess OP didn’t want to pay the communication tax on expressing this idea clearly :)

Re: Learning Software Architecture

#95

Post by tomhow »

woodydesign wrote: post #20
supriyo-biswas wrote: post #14

Earlier quoted context omitted.

[flagged]

Correct — LLM helped with the wording. The thought is mine. As a non-native English speaker, I’m pretty happy that the final version is more readable and probably sharper than what I would have written alone.

We understand you feeling like it's more important to post polished writing than imperfect writing, as a non-native English speaker. But neither the HN audience nor the guidelines (https://news.ycombinator.com/newsguidelines.html) see it that way.

AI-translation/editing/polishing takes away all the authenticity and makes the writing seem like it came from a machine, not a person. It's much better if you write in your own voice, even if there are imperfections. The HN audience appreciates the effort.

Re: Learning Software Architecture

#96

Post by miki123211 »

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 unfamiliar to the project will interact with them, make the obvious way be the correct way.

- Correct code should be easy to write; suspicious code should stand out.

- Shift bugs left.

- Fixing a bug class is better than fixing a bug.

- Interfaces are harder to change than implementations. An ugly implementation is ok if it has the correct interface.

- Use comments and documentation to explain why the code is the way it is. If it feels like there's a simpler way to do it, but that simpler way wouldn't actually work due to a constraint some people may be unaware of, document that.

- Don't repeat yourself; when it comes to data. If you store a single fact in multiple places; those places will inevitably get out of sync, and that causes bugs.

- There's a cost to straying off the well-trodden path. Don't be afraid to do so when it's truly worth it, but don't underestimate that cost. Worse (boring) technology is often better technology.

- Think in terms of expected value. Think not "Is this thing worth doing?", but "Is this thing worth doing, compared to the other things we could be doing instead?"

- Even if you think you're smarter than everybody else, intelligence isn't always enough, some problems can't be discovered until they happen. Other people have worked longer on this problem than you have. Learn from their mistakes.

- Friction is the silent killer.

Re: Learning Software Architecture

#97

Post by embedding-shape »

kachnuv_ocasek wrote: post #88
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…

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

Depends on the language I'd say, but overall, try to keep state in as few places as possible, and make it more obvious when it's being used. Modern example would be Rust defaulting to immutability for variables, and makes it very clear when you should expect that this variable actually carries state rather than just a value, by prefixing it with `mut `. Other languages might make it the other way around, making constants/read-only variables stick out, and defaulting to "hiding that they have state" basically.

Re: Learning Software Architecture

#98

Post by pelasaco »

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…

then comes the order from your manager: "Put it in production and we can work through this list later".. or even worse, now with Claude, managers are putting stuff "Quick and Dirt" in production and you have to maintain it.. sadly true story..

Re: Learning Software Architecture

#99

Post by RobRivera »

embedding-shape wrote: post #92
RobRivera wrote: post #56

Earlier quoted context omitted.

I wish I could buy you a beer, as this is very validating. I have been building a video game for over a year. But more importantly I have been building a sustainable engine with a distinct data pipeline, resource rendering/management layer fully decoupled, explicit catalogueing of viable state transformation modes, and honestly, most of your list is absolutely applicable. Even tho it is solo, the constraints of my en…

Ah, the infamous "I believe I'm building a video game, but in reality I'm building a video game engine and I don't realize it yet" every game developer goes through at least once, god speed to you :)

Its been such a fun endeavor

Re: Learning Software Architecture

#100

Post by munk-a »

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 work in this space as well - I know that my particular work is much less abstract (we're modeling the healthcare industry) than some others.

But as a designer of the system you must understand the industry and while you don't need to embrace their terminology and modeling habits fully, you must understand their rationale and how they view the data set. There are some places where we've intentionally simplified complications of the healthcare market to eliminate needless (to us) over definitions and provide a more unified modeling. But these changes took significant comprehension of the problem area to make with confidence.

> You should spend more time thinking about naming things correctly.

On this point in particular. Names never die - that's a lie, occasionally they do, but it takes an extreme amount of effort to enforce a renaming. It really is worth spending a big bulk of time letting SMEs stew with naming proposals to make sure you bases are covered. You can force through a few concepts but your business wing (sales, marketing) will constantly put pressure on you towards industry terminology and force your model to adhere to the current view of the industry. If you decide to break with that that break must be decisive and obvious in intent.

Oh, the single biggest attribute of software to emphasize is maintainability. How much will this cost to build is one question - how much will this cost to run (not just infra but compounding feature requests and code refactoring and maintaining third party software versions etc...) is the far more impactful.

Post reply on HN