←back to thread

1457 points nromiun | 4 comments | | HN request time: 0.543s | source
Show context
exclipy ◴[] No.45077894[source]
This was my main takeaway from A Philosophy Of Software Design by John Ousterhout. It is the best book on this subject and I recommend it to every software developer.

Basically, you should aim to minimise complexity in software design, but importantly, complexity is defined as "how difficult is it to make changes to it". "How difficult" is largely determined by the amount of cognitive load necessary to understand it.

replies(11): >>45077906 #>>45077954 #>>45078135 #>>45078497 #>>45078728 #>>45078760 #>>45078826 #>>45078970 #>>45079961 #>>45080019 #>>45082718 #
YZF ◴[] No.45078760[source]
The problem is no set of rules can replace taste, judgement, experience and intuition. Every rule can be used to argue anything.

You can't win architecture arguments.

I like the article but the people who need it won't understand it and the people who don't need it already know this. As we say, it's not a technical problem, it's always a people and culture problem. Architecture just follows people and culture. If you have Rob Pike and Google you'll get Go. You can't read some book and make Go. (whether you like it or not is a different question).

replies(9): >>45078947 #>>45079055 #>>45079393 #>>45079903 #>>45079931 #>>45079994 #>>45080208 #>>45080993 #>>45083102 #
1. mnsc ◴[] No.45080993[source]
> You can't win architecture arguments.

I feel this in my soul. But I'm starting to understand this and accept it. Acceptance seem to lessen my frustration on discussing with architects that seemingly always take the opposite stance to me. There is no right or wrong, just always different trade offs depending on what rule or constraint you are prioritizing in your mind.

replies(3): >>45081113 #>>45081624 #>>45083244 #
2. berkes ◴[] No.45081113[source]
I've found that listening and asking questions is the key to accepting other people's architectural choices.

Why do they insist on A over B? What trade offs were considered? Why are these trade offs less threatening than other trade offs? What previous failures or difficulties led them to put such weight on this problem over others?

Sometimes it's just ego or stubbornness or routine¹. That can and should be dismissed IMO. Even if through these misguided reasons they choose the "right" architecture, even if the outcome turns out good, that way of working is toxic and bad for any long term project.

More often, there are good, solid reasons behind choices, though. Backed with data or science even. Things I didn't know, or see different, or have data and scientific papers for that "prove" the exact opposite. But it doesn't matter that much, as long as we all understand what we are prioritizing, what the trade offs are and how we mitigate the risks of those trade offs, it's fine.

¹ The worst, IMO, is the "we've always done it like this" trench. An ego can be softened or taken off the team. But unwillingness to learn and change, instilled in team culture is an almost guaranteed recipe for disaster

3. KronisLV ◴[] No.45081624[source]
> Acceptance seem to lessen my frustration on discussing with architects that seemingly always take the opposite stance to me. There is no right or wrong, just always different trade offs depending on what rule or constraint you are prioritizing in your mind.

That’s a stance of acceptance, however I’d say that there are people who are absolutely wrong by most metrics sometimes and also stubborn to the point that you’ll never convince them. Ergo, the frustration is inevitable when faced with them.

4. vitaflo ◴[] No.45083244[source]
The problem with a lot of devs is trying to win arguments instead of coming to a consensus. What’s best for the team matters more than what’s best for the individual and every team is different.