Live data from Hacker News

Learning Software Architecture

matklad.github.io

51–60 of 133 posts

Re: Learning Software Architecture

#51
post #44

Earlier quoted context omitted.

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

Completely agree. Had me until the very last point. WTF. Communicate.

The last one is about involving less people. You don't have to read it as "shut up and keep your thoughts for yourself". I read it more like "Do we really need to have six people working on this feature/present in this call?"

Re: Learning Software Architecture

#52

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

Re: Learning Software Architecture

#53

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…

As a corollary to

> Communication is a tax that you should justify before paying it.

> Every piece of information should have a single source of truth.

- Do as much as possible on a single system and minimize sharing state.

- Recognize that every system is distributed, it's just a question of how and where.

One of the biggest ills I observe with most modern software systems is that we've gone full tilt towards things like microservices which require synchronizing state across multiple interdependent parts. Regardless of how clean the abstractions or how well contracted the APIs, doing all of that copying and state synchronization is going to result in problems: performance problems, cost problems, and synchronicity problems.

Re: Learning Software Architecture

#54
As relates to Systems Engineering: Software architecture is like plumbing architecture. It's certainly very important, but you don't live in plumbing pipes, you live in a house with plumbing. If your plumbing doesn't take the rest of the house into account, it could be a very expensive fix.

Re: Learning Software Architecture

#55

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…

> - Make state explicit.

Don't save the same state in more than one place.

Re: Learning Software Architecture

#56

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 engine guides forgetful me to 'this is the way to add this weird new feature that arose from testing because reasons' without having to have a tome of 'if you want to build a new sound effect that executes at a particular state transformation multiple times, here is how you do it'

Cheers

Re: Learning Software Architecture

#57
post #44

Earlier quoted context omitted.

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

Completely agree. Had me until the very last point. WTF. Communicate.

I wonder if they don't mean "between systems".

Re: Learning Software Architecture

#58
post #6

I would like to spend my time more on gaining a mental model of the projects I work on, but I get very demotivated if I start disliking things like the programming language, certain arch. Choices or anything that gets too complex that doesn't seem like its worth my time It's heavily dependent on the project, but I feel like working as a "fullstack dev" kind of removes the fun of programming. I'm already spending 40 h…

Sounds like you need better emotional regulation.

Re: Learning Software Architecture

#59
post #51

Earlier quoted context omitted.

Completely agree. Had me until the very last point. WTF. Communicate.

The last one is about involving less people. You don't have to read it as "shut up and keep your thoughts for yourself". I read it more like "Do we really need to have six people working on this feature/present in this call?"

well, it needs to be communicated better.
Post reply on HN