Comment by a_c | Hacker News Reader

Comment by a_c | Hacker News Reader

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

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.

Bats are single celled?

On the contrary, once you start digging down into details, you'll see living things made of multi-purpose components with fuzzy boundaries, going very much against "single responsibility principle" and the like. That's because evolution isn't like human engineers, who need to walk up and down the abstraction ladder so things they care about fit in their head. Evolution is brute-forcing the problem space, using a greedy optimization algorithm. It doesn't need to remember anything.

> People seem to talk more about infinite scaling is a fool's errand. I say so is specialising without seeing the forest first.

I started first disagreeing with your point, but I think this last sentences captured what sticked to me. That's similar to the rule of three practice (three strikes and you refactor).

I find it's always hard to keep the whole team aware of the forest, maybe that's why I've seen many premature specialization.

How do we keep a team aware of the forest?

People seem to have an intuitive understanding on what matter the most to a ramen shop. Have ramen, get eaten, happily, in that order. And then we can talk about decor, hygiene, side dishes, etc. It is so muddy when it comes to software. People spend endless energy debating a lightbulb of a ramen shop. "What is your ramen? What is OUR ramen?" is something I try to bring up to the team with varying success. Sometimes it is more effective just telling people what to do. If we see people as code, then some of them are of single responsibility with simple interface. It really depends what kind of a team we want.

WRT. the comparison to a ramen shop, it would seem that the "intuitive understanding on what matter the most" is all about the product, and the value and experience it delivers. In software, almost all of the debates are about the process. Code style, culture, CI/CD, code reviews, scrums and scrams... this is all process. The product? I suppose it's kind of a given. Or perhaps just not in power of the programmers to influence enough. IDK. There's some depth to be extracted from your analogy.

Communication, with clarity and repetition.

Communication, which is something some people/teams/organizations are better at than others.

Also, some people are better system thinkers than others, usually more experienced. You need someone to understand everything at a deep enough level to be able to teach it on every team.

Reply on news.ycombinator.com