Comment by matheusiacono
2 years ago
> 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, 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.
Communication, with clarity and repetition.