Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Philosophy of Software Design

web.stanford.edu

Post reply on HN
Print view View original

11–20 of 116 posts

Re: A Philosophy of Software Design

#11

Post by codeflo »

cc_ashby wrote: post #5

[redacted] are my favorite people on complexity. [redacted] was notably my professor for operating systems @ [redacted]. He taught not just ways to design software, but also ways to live. [redacted]’s work is also directly influenced by [redacted], as referenced at the end of his article. For [redacted], I suggest looking at the class website: [redacted] For [redacted], I suggest his book, [redacted]

I'm a fan of Ousterhout's writing; "A philosophy of software design" clarified a lot of my thinking around complexity.

I find the "Grug Brain" stuff pretentious and dishonest. "Me not smart. Me like simple things. Me not believe in hype. Hence why me invent complex new frontend framework, and then me hype it up beyond reason."

(To be clear what I'm saying, my point is not that HTMX is overhyped -- it might be, but then so is everything. It's specifically the hypocrisy of the "we're against hypes" hype that makes me cringe.)

Re: A Philosophy of Software Design

#12

Post by ludston »

mparnisari wrote: post #7

His book is awesome! One takeaway I had: code reviews matter. If your code is undergoing review and a reviewer tells you that something is not obvious, don’t argue with them; if a reader thinks it’s not obvious, then it’s not obvious.

But don't forget that there are two reasons why something will not be obvious: It may not be obvious because the meaning is obfuscated, or it may not be obvious because it relies on the reader understanding certain ideas, concepts or technologies.

Re: A Philosophy of Software Design

#13

Post by a_c »

Haven't read the book yet but it seems to be about design principles, abstraction, divide and conquer, single responsibility and the like. Man made objects tend to be single-purposed and interact with few other components. Over the years I have come to appreciate the nature more and more. In nature, things are always multi-purposed and exist in a web of relationship. A bat is a pollinator, pest control, fertilizer and food source all at the same time. But if we are to replicate the role of bat, we need seed, pesticide and artificial fertilizer. And if we want to grow only one kind of crop, we will need even more control. See monoculture [1]

In software, every named domain can and will grow into its own forest. There was only nginx(or apache) serving html. There wasn't "frontend" and "backend". Nginx served also the analytics. Now they all seem to mean its own thing. There are and always will be manual interacting with the software. What we do is first manually interact, and then write automated script, and then manually interact and make demo video, and then manually interact and make tutorial, and then manually interact and illustrate the user journey, etc. Telemetry is "engineering", analytics is "product". The division goes on forever. Man made concept grows into isolated forest. The more division, hence specialisation, we have, the more gluing we need. People seem to talk more about infinite scaling is a fool's errand. I say so is specialising without seeing the forest first.

I find occasionally zoom into other direction immensely helpful and refreshing.

[1] https://en.wikipedia.org/wiki/Monoculture

Re: A Philosophy of Software Design

#14

Post by rTX5CMRXIfFG »

a_c wrote: post #13

Haven't read the book yet but it seems to be about design principles, abstraction, divide and conquer, single responsibility and the like. Man made objects tend to be single-purposed and interact with few other components. Over the years I have come to appreciate the nature more and more. In nature, things are always multi-purposed and exist in a web of relationship. A bat is a pollinator, pest control, fertilizer an…

That’s because your example, a bat, is a high level of abstraction. If you dig into the cellular level things start becoming very single-purpose, even more so down to the atomic level, and so on. The architecture of recursive composition usually done in building large software was found in nature first.

Re: A Philosophy of Software Design

#15

Post by corethree »

lvturner wrote: post #9
corethree wrote: post #6

An alternative viewpoint on software: https://www4.di.uminho.pt/~jno/ps/pdbc.pdf Rather then using blurry fuzzy concepts about software. This book is called "Program design by calculation". Which is to view software through the theoretical lens of math, science and engineering rather then "philosophy". Should software design be interpreted using the blurry and hand wavy concepts of philosophy and literature? or shoul…

Do the business requirements (fundamental assumptions around design to be more generic) of a bridge, car or airliner change dramatically over time? I'd argue not. Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive.

>Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive.

What formal theory have you ever used for designing your software? I would argue you've never used anything. Every abstraction you've ever made was likely a gut feeling, an instinct or following some vague hand wavy rule of thumb.

At best we use type theory for type correctness and complexity theory to calculate efficiency. That's basically as far as it goes with "theory" and these two things aren't even about "software design".

Software design in practice as most engineers use it today is, practically speaking (key phrase), 100% art. Sometimes people come up with big fancy words like "dependency injection" or stupid Acronyms like SOLID to create the illusion of formal theory, but these things are nothing of the sort. It's just tips and tricks.

The plane, the car, the bridge? Those things use both design and formal theory... software design as most engineers use it, again, does not use ANY formal theory, it's almost just purely design all the way down.

Re: A Philosophy of Software Design

#16

Post by rgoulter »

One thing I liked about the book was it emphasised the conceptual difference between 'interface' and 'implementation'. "Interface" is "what you need to know to use the module".

Some module is "complex" if you need to know more than the interface suggests in order to use that module (e.g. you have to know implementation details); or if the interface requires irrelevant details.

Re: A Philosophy of Software Design

#17

Post by dang »

Related. Others?

A Philosophy of Software Design – Book Summary and Notes - https://news.ycombinator.com/item?id=31248641 - May 2022 (34 comments)

A Philosophy of Software Design, 2nd Edition - https://news.ycombinator.com/item?id=28975872 - Oct 2021 (1 comment)

Book Review: A Philosophy of Software Design (2020) - https://news.ycombinator.com/item?id=27686818 - June 2021 (61 comments)

Book Review: A Philosophy of Software Design - https://news.ycombinator.com/item?id=18331219 - Oct 2018 (51 comments)

Notes on “A Philosophy of Software Design” - https://news.ycombinator.com/item?id=17906662 - Sept 2018 (32 comments)

Re: A Philosophy of Software Design

#18

Post by ludston »

lvturner wrote: post #9
corethree wrote: post #6

An alternative viewpoint on software: https://www4.di.uminho.pt/~jno/ps/pdbc.pdf Rather then using blurry fuzzy concepts about software. This book is called "Program design by calculation". Which is to view software through the theoretical lens of math, science and engineering rather then "philosophy". Should software design be interpreted using the blurry and hand wavy concepts of philosophy and literature? or shoul…

Do the business requirements (fundamental assumptions around design to be more generic) of a bridge, car or airliner change dramatically over time? I'd argue not. Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive.

Mathematics and science can both be viewed as very fleshed out and practical branches philosophy, so they certainly aren't mutually exclusive.

Re: A Philosophy of Software Design

#19

Post by lvturner »

corethree wrote: post #15
lvturner wrote: post #9

Earlier quoted context omitted.

Do the business requirements (fundamental assumptions around design to be more generic) of a bridge, car or airliner change dramatically over time? I'd argue not. Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive.

>Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive. What formal theory have you ever used for designing your software? I would argue you've never used anything. Every abstraction you've ever made was likely a gut feeling, an instinct or following some vague hand…

Just because it doesn't use formal theory now --- does not mean it/we shouldn't use it. I'm talking about needs, not haves.

Re: A Philosophy of Software Design

#20

Post by pamoroso »

buzzwords wrote: post #8

Is this good going to be readable on Kindle? It might be just me, but some software engineering books are hard to read on Kindle due to codes sections could end up with strange format.

No problem on Kindle, the book is mostly text and has only a handful of short code snippets.
Post reply on HN