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.
Learning Software Architecture
51–60 of 133 posts
Re: Learning Software Architecture
#52I'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…
One addition?
* start with a modular monolith
Re: Learning Software Architecture
#53I'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…
> 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
#54Re: Learning Software Architecture
#55I'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…
Don't save the same state in more than one place.
Re: Learning Software Architecture
#56I'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…
Cheers
Re: Learning Software Architecture
#57Re: Learning Software Architecture
#58I 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…
Re: Learning Software Architecture
#59Earlier 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?"
Re: Learning Software Architecture
#60[flagged]