Comment by vrnvu | Hacker News Reader

Comment by vrnvu | Hacker News Reader

So what the author is suggesting is basically improving cache locality using linear data structures. Use data structures that fits your CPU/GPU. Use algorithms that make good use of your CPU/GPU... Add branch prediction and good memory alignment to reduce page faults to the mix and you have the A, B, C of data-oriented design.

Now, in order to apply this ideas to a higher level of design, i.e communication between microservices, we need to apply the same principles. Reduce expensive calls by sending all data required to a function at the same time, let the backend do the work, precompute/prefetch data that will make work easier later...

Good advice in general. For me the highlight is that this approach can only be applied when we design and adapt our microservices to our computational needs instead of business. I still see a lot of gurus giving talks about splitting microservices in "business needs" and saying that anything else is a bad practice. Hold on, there is no silver bullet in engineering. Maybe the business logic is easy to understand, but this system design will make the system impossible (yes) to optimize in the future without a full re-write. And the same idea applies to low level design. Everything is a trade-off.

My approach is to design the public API following domain/business principles so it's easy to understand and implement. A la DDD and others if you want to call them something. But I want my backend to be flexible and designed around the REAL engineering requirements. If my `/api/foo/bar` is an async batch process that needs to be cached and my `/api/foo/baz` is a complex sync process, then `bar` and `baz` are two completely monsters. I don't want to have a `foo` service to handle both use cases. Having a `foo` service just because it's a business concept will cost you hours and money.

> I still see a lot of gurus giving talks (...) saying that anything else is a bad practice.

I have become very cautious when "gurus" speak about good/bad practice. My personal approach is to ask them which ultimate goal they intend to reach by that, and how their "good" practice is intended to reach that goal.

Note that I'm not asking for certainty at all, or even a high chance. Just a clear intention. More often than not, they cannot outline a path from their "good" practice to their end goal. If they can even name a goal, that is.

My favorite examples are splitting methods to reduce their size, and user story estimation (applies to both story points and man-days). No clear path to an end goal, not a single time so far.

I've become cautious when people caution about guru's with an air of authority.

> My favorite examples are splitting methods to reduce their size, and user story estimation (applies to both story points and man-days). No clear path to an end goal, not a single time so far.

Who here believes you asked that of someone and they couldn't give you an answer involving the words "simplicity", "readable", "understandable", etc?

> I've become cautious when people caution about guru's with an air of authority.

Don't get me wrong, I would like to have a similar discussion with an actual subject expert, just most "gurus" aren't experts but just cargo-culters.

> Who here believes you asked that of someone and they couldn't give you an answer involving the words "simplicity", "readable", "understandable", etc?

I never claimed that they didn't give such an answer. What they did is give an answer that involved all these words, but without even the ability to define them except through the very same metrics that were supposed to measure them, i.e. circular reasoning.

The particular case of "readability" was the claim that breaking a long method into short ones increased readability, based on a vague idea (not a definition) of readability. I literally showed the code to a dev not involved in the project who was able to read and understand the long-method version better. While admitting the sample size of two (repeated that experiment once), I could give a very clear definition of readability.

I cannot give a similar example for "simplicity" and "understandable" since they were even less able to pinpoint those terms. I would have liked to argue at least on the basis of SOLID principles, but we never reached that point because method length (in lines) was more important to them.

I think the metric should be branching, so functions with fewer branches are better than functions with more branches.

And the reason is that it’s easier to write tests for functions with few branches without overlooking paths through the function. Same goes for reasoning, it’s easier to consider all paths through a function if there’s fewer.

I see number of lines as an imperfect proxy for complexity.

Generally a good metric, but be aware that overapplication would ultimately result in linear searches: https://news.ycombinator.com/item?id=32507510

This smacks of an argument over a PR.

subjective reasons are still reasons, and they can still be valid reasons.

Reply on news.ycombinator.com