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

71–80 of 133 posts

Re: Learning Software Architecture

#71

Post by mpweiher »

skydhash wrote: post #38
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…

> if procedure calls are the assembly language, what might a high level language look like? I’m not well versed in PLT and SWE tooling, but isn’t that the base concept around lambda calculus, LISP, APL, clojure, TCL,…? You only need a few data structures and types, a small collection of fundamental functions, then you compose them. If there’s one thing that I like about Lisp is that more complex type are always opaqu…

> You only need a few data structures and types, a small collection of fundamental functions

For the implementation: yes. Hence "assembly language". The mistake almost universally made is to confuse that with the abstraction mechanism.

She showed that it's necessary.

I showed how to do it.

Re: Learning Software Architecture

#72

Post by rawgabbit »

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!

Not the OP. However, in my experience, the "tax" of communication is that everything has winners and losers. You can state that the "1+1=2" or "the sky is blue" and someone will lose politically. You have to prepare yourself to defend your position even if 19 out of 20 agree with you; because the one person who disagrees with you has the most to lose.

Re: Learning Software Architecture

#73

Post by luodaint »

The architecture assignment that I found most useful did not come from a book. It involved the attempt to articulate my system to an agent session starting with no background information at all.

If the agent cannot deduce the constraint, then you have to write it out. Conventions for migration. Invariant properties of the authentication protocol. Multi-tenant behavior. This act of articulation – making your implicit reasoning explicit – led to a kind of clarity that several months of construction alone did not bring. Three architectural errors emerged instantly.

It’s true that learning by doing is the way to go. I would add: learn by explaining it. The agent is an unusually picky audience.

Re: Learning Software Architecture

#74

Post by 4b11b4 »

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 ).

Residuality is very interesting. Have you used it in practice?

Re: Learning Software Architecture

#75

Post by embedding-shape »

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 with "right tool for the right job", the easier time you'll have designing, because you're no longer trying to shoehorn in things that are "right" and "correct".

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

This should almost be on the list twice too, the amount of people who couldn't care less about naming, is so damn high, but if people just cared a tiny bit, it'd solve so much future confusion. Whenever I get pulled into helping a "legacy project" or whatever, establishing a "true vocabulary" based on what people actually call things, is the very first thing to do, because it always uncovers that people been talking about different things the entire time.

Re: Learning Software Architecture

#76

Post by ivanjermakov »

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…

> If testing is difficult, the design is wrong

Or domain/IO is cumbersome. Think videogames.

Re: Learning Software Architecture

#78

Post by embedding-shape »

ivanjermakov wrote: post #76
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…

> If testing is difficult, the design is wrong Or domain/IO is cumbersome. Think videogames.

That's one of the few places where creating abstractions makes a lot of sense, especially in video games. You really, really want as much to be automated tested as humanly possible, because the user/player surface ends up enormous and testing gets "expensive" much quicker than a typical SaaS.

Re: Learning Software Architecture

#80

Post by nullsanity »

ivanjermakov wrote: post #76
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…

> If testing is difficult, the design is wrong Or domain/IO is cumbersome. Think videogames.

Nope, that's just the design being wrong. Factorio has no issues with testing.

It doesn't matter if nobody is interesting it fixing it, video games have been and almost always are written like shitty single use code, (Even when it's not) so it shouldn't surprise anyone that proper test harnesses aren't available in engine.

Post reply on HN