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

101–110 of 133 posts

Re: Learning Software Architecture

#101

Post by munk-a »

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”?

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.

Re: Learning Software Architecture

#102

Post by munk-a »

murkt wrote: post #49
mwexler wrote: 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!

You can make the feature with one colleague, or you can call in five more people to weigh in and do their parts of the work. If you involve five more, the result could be better in theory, but it will certainly take MUCH more time because of communication overhead.

Pretalking is highly valuable. Making sure that key stakeholders have an aligned vision and are invested in defending it before opening up a discussion (or dictate, depending on the culture) to a wider audience is necessary. Occasionally expect that the stakeholders and you got it wrong and you'll need to invest time into rebuilding the solution, but, if you're honest with yourselves and diligent, assume that generally the expert subgroup will supply a comprehensive solution.

Re: Learning Software Architecture

#103

Post by munk-a »

murkt wrote: post #51
theteapot wrote: post #48

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?"

I strongly prefer the phrasing of "When do we actually need to have six people involved on this?" It's often valuable to set a momentum and prune obviously poor decision branches before bringing proposals to a wider audience.

Re: Learning Software Architecture

#104

Post by munk-a »

ofrzeta wrote: post #55
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…

> - Make state explicit. Don't save the same state in more than one place.

You can and you must replicate state in a complex system. The key is that state should always have an explicit owner and other carriers of that state should understand that their version of the state has some inherent lag or inconsistency off the true state.

There's a reason caching (and it's invalidation) is one of the two hardest problems in computer science.

Re: Learning Software Architecture

#105

Post by munk-a »

avgDev wrote: post #89
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, although things get weird when you are limited by some legacy software/database.

You are always limited by some legacy software/database.

If you're not limited by some legacy software/database initially then you will have such a large problem scope that you'll create your own legacy software/database internally.

I'll grant that if your problem is really simple and straightforward you can sometimes just build an ideal greenfield solution that's perfect and wonderful - but those problems are rarely the problems that are profitable to solve.

Re: Learning Software Architecture

#106

Post by munk-a »

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

I don't want that to be limited to just architecture though - proper initial factoring of a software product is invaluable at the large and most microscopic level.

Re: Learning Software Architecture

#107

Post by munk-a »

pelasaco wrote: post #98
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..

The job of an architect and good technical management is to teach non-technical management the true costs of their decisions. It's not an easy job by any measure and LLM driven know-nothings in management can make it far more frustrating. But, you need to make sure you're capturing the true[1] costs of decisions to the best of your ability including externalities.

1. You're allowed to lie for expediency, but make sure you never delude yourself into believing your own lies.

Re: Learning Software Architecture

#108

Post by mpweiher »

sroerick wrote: post #93
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?

https://www.google.com/search?q=hexagonal%20architecture

First result:

https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa...

Re: Learning Software Architecture

#109

Post by munk-a »

ah1508 wrote: post #66

I think that words like "clean code" or "beautiful code" does help juniors to learn best practices of software architecture. - Junior asks to senior: what did you we use an ORM ? - senior answers: because it's cleaner. - junior: ??? I prefer when people are able to define a clear list of objectives: - maintenable; - performant, scalable; - efficient; - resilient; - observable; - testable (and tested); - secured; - re…

Modular frameworks are worth their weight in gold when compared to "highly opinionated frameworks". I don't mind something that's highly opinionated - and highly opinionated is an excellent trait for a library or tool. That lib/tool likely has a large amount of domain expertise in the particular area it operates in.

When it comes to frameworks - highly opinionated tends to get corrupted into "We have this hammer and suddenly everything looks like a nail" - it doesn't always happen and it doesn't always bite you but when orthodoxies are taken from one domain and applied broadly you run the risk of some of the justifications for that orthodoxy being domain specific and being violated in the wider context.

So, when it comes to frameworks, I like modularity where I have options to plug in a different ORM or persistence integration layer - where I can swap out the router - or the validator - or any other component that proves a poor fit for our problem. It is especially valuable if there are multiple paradigms expressed in alternatives within the framework's ecosystem since you may find a pre-baked tool that mostly works where you can choose an option with shortcomings that are clear and addressable if ever the need arises.

To support maintainability it's very important to fight against NIH-ism, that is a constant danger that can soak up resources at an alarming pace - but it's also important to realize that there are some components that you will greatly benefit from tweaking or taking full ownership of with the most difficult problem being trying to figure out which is which.

I appreciate deeply that your list put maintainability first - that's my opinion as well!

Re: Learning Software Architecture

#110

Post by munk-a »

ramon156 wrote: 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…

Analysis paralysis is a danger always - don't aim for perfect, but aim for flexible. Make sure the decisions you're spending the most time on are the most important.

A well designed data structure is far more impactful on performance and maintainability than framework, language or platform.

Personally, I work alongside ADHD every day so I need to constantly push to make sure that progress is happening which means picking unimportant decisions and resolving them to focus the remaining open problem space on the decisions that require a lot of careful thought.

Post reply on HN