Hacker News Reader

> I think those are good engineering decisions (depending on the problem domain).

The "depending on the problem domain" seems another variant of "choose the right tool for the right job". One could probably add "for the right reason" on the end of that instruction too, and it wouldn't hurt.

The problem is the ability to determine "the right tool" and "the right job" - many people simply don't have it. You only get that ability through experience. With new tools few people - even older folks - have enough experience with the tool in question to make accurate/useful assessments.

> but hey, the internet is full of really talented smart people who do excellent engineering work.

And it's full of even more people who aren't really capable of making those assessments accurately.

> You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it.

You'd be stupid to think that because "Facebook" (or "Amazon" or "Google" or "MS") is using a particular tech stack (which, likely, teams of internal people contributed to for months), it's a great fit for your problem, or your skills, or your team's skills, or your project's timeline, or its budget. Few people have the problems or demands that Facebook/Amazon/Google/etc have. It's great that they share some of their internal tech, but that sharing isn't an automatic determination that their solutions are appropriate fits for your problems.

This basically what I'm talking about.

Ok, if what the smartest and best people are doing isnt the right solution for my problem, what is?

Come on; enough vague hand waving. How do you pick the right tech to use then?

What if your development team is made up of mediocre programmers? What works for the most talented programmers isn't necessarily going to work for your team.

In my experience the choice of the right tech is primarily a business decision rather than a technical one. By that I mean it should be based on a number of factors external to the technology. Once you have clearly identified the business problem you are trying to solve, you have to think of the solution in terms of risk. For example, what is the up-front development risk? What are the maintenance risks?

Every project exists within a certain environment with its own set of constraints. Picking the right solution means understanding these and doing so from the point of view of the business.

If you understand the risks and constraints, and you put the needs of your end-users, the systems administrators, the testers, and the business first you will rarely go off-track.

Not that I really disagree with you, but I find that "risks", "constraints", "end-users", "systems administrators", "testers", and "the business" are six separate forces, each pulling in their own direction, and you can't put them all first.

Find myself in agreement with both of you. As you say you can't put them all first, however I've found anecdotally that risk and constraints are disproportionally placed last in many orgs.

Of course, there's the opposite extreme too, where long time team members and management ivory-tower themselves to micromanage every tech choice and then prescribe it throughout an organisation without much input.

>Ok, if what the smartest and best people are doing isnt the right solution for my problem, what is?

Obviously only what "the smartest and best people are doing" to solve problems that are isomorphic to yours.

But first you also need to identify those people: who said those in the big companies (or smaller with better bloggers) are the "smartest and best people"? Just because they belong to a succesful company? And because they have degrees from some top-tier university?

The company could be succesful despite of its technology, on the business value alone (which usually is how it is), and the people with "good degrees" could just be architecture astronauts or fresh amateurs who re-invent long buried concepts because they don't know better.

There's a whole long distance between what the current industry champions as "best minds" (some 20 year old with 2 years of JS that created the framework du jour) and people like Knuth, Alan Kay, Kernighan, Richie, Bill Joy, and the like...

Facebook is the world's largest PHP shop. Does that mean that everyone should use PHP?

As it turns out, moving fast and breaking things isn't all that conducive to quality engineering[1][2]. Facebook has a massive legacy code base maintained by an enormous team that is under pressure to iterate quickly while supporting what is arguably the world's largest user base. They are dealing with extremely specialized constraints that most of us will never encounter. Many of the trade-offs they consider acceptable aren't trade-offs that make sense elsewhere.

And that's exactly what the blog post is getting at. A lot of these emerging technologies are situationally useful in a particular set of scenarios and environments, but developers with cargo cult mentality convince themselves that these things will solve all of their problems if they use them everywhere. When the disappointment sets in and they figure out that isn't the case, yesterday's darling stack becomes the subject of today's "considered harmful" essays and everybody moves on to the next shiny thing.

The point here is that maybe you should make a sober assessment of new technologies and objectively evaluate whether they are actually practical for your usage scenario rather than just blindly jumping on the bandwagon and using something.

The examples from the blog post are totally on point. I previously worked at a company that built a NoSQL database and I have great affinity for the technology, but there's no question that too many people adopted NoSQL databases without really understanding the trade offs. People want to be "web scale" so they go straight to using databases that are designed for high-availability clustering even when they are building applications that would be perfectly fine running forever on a single postgres instance.

[1] https://www.darkcoding.net/software/facebooks-code-quality-p... [2] http://blog.timac.org/?p=1707

I agree with the general sentiment, but, to nitpick, Facebook uses/is transitioning to http://hacklang.org/ to avoid PHP. They literally wrote a whole new language and built a VM to do JIT compilation of that new lang just to not have to continue using PHP.

> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).

Hype does not mean that a popular technology should never be used. It's when people overrate and overuse it and try to apply it to the wrong domain.

The examples are spot on.

Yes, for example NoSQL and MongoDB .

Ppl had no idea about relational databases and thought that's a good case for not using them.

Yes. Google and Facebook who pioneered NoSQL with BigTable, HBase, Cassandra etc have no idea about relational databases. Likewise all of the enterprise companies who have spent tens of millions on relational EDW systems and are adopting NoSQL in droves also don't understand what they are doing.

But thankfully we have some no-name developer to save us from all of these mistakes. No use cases for NoSQL. Give us a break.

Oh, so now we're beating strawmen again. Nice!

They didn't say the technology itself was poor, but that people have misused it.

>we have some no-name developer to save us from all of these mistakes.

Both rude and fallacious. Do you presume that every employee at a successful firm is a wunderkind? Do you actually know the level of talent of every HN poster?

Relational databases have their advantages and disadvantages just like NoSQL. They both make tradeoffs. Taking the trouble to understand which is the right tool for the job instead of following the latest fashion trend is what the article is about.

> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).

> I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid...

I feel like you're shooting right past the author's point here. What he's saying is that hype, as in the shared excitement, obscures the actual tradeoffs involved in adopting the new technology, and makes it harder to make good engineering decisions.

I'd like to add that it also obscures the available alternatives - simple and straightforward ways to configure / extend existing technologies to have the same behavior / features as that shiny new thing.

And it's not even about what you know ahead of time. I was actually thinking about this earlier today: I often recognize some of the tradeoffs of adopting a new tech early on, but my judgement still often ends up clouded by enthusiasm.

A common pattern of rationalization I often have goes like this:

"Sure this old thing can be used to do the same as this new thing by using functions X,Y,Z, but this new thing lets you do it with just one function. I mean sure, I could write that function myself in about 10 lines, and I only need to do this once for each project, but this is just easier."

I'm not saying that this reasoning is wrong, only that it is biased.

Tradeoffs of a technology, and therefore knowing in which problem domain they are most appropriate, consist of both pros and cons.

The problem with hype isn't that the technology being hyped is not excellent in its own way, the problem is that (psychologically) hype leads us to ignore the cons, to rationalize them away - and this means we're not really fairly considering the tradeoffs.

The author isn't saying that microservices, react, Elixir, NoSQL, etc don't have upsides, but only that (if we are not extra careful) we might not be considering the tradeoffs and alternatives as pragmatically as we think we do.

> ...but hey, the internet is full of really talented smart people who do excellent engineering work.

It's actually not. It's full of average people who do mediocre engineering.

I've definitely seen overuse of React, microservices, and NoSQL databases before it makes sense or when it's actually a detriment to complexity.

This point from the article however, I agree is a bad example.

> Example 2: TDD is dead by DHH

The 37signals guys if anything are some of the realest in terms of low fidelity tools and sensible abstractions and building things simply. They've even written two books about their approach to business and web app development (Rework, Getting Reals). Maybe there is concentrated hype around Rails but in general their stuff is well informed and well thought out.

>I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).

The two are orthogonal. Hype is a marketing force which can be used to tout good and bad stuff.

Teams can just as well adopt a good product if its hyped. That doesn't mean their adoption process was based on a "good engineering decision". Just that they lucked onto making one.

That said, I find "microservices" or "no sql" as more hype than substance in the domains that most teams apply them. They just reimplement (poorly) a ton of stuff that a monolith or sql would already have, and don't really need either for their use case.

These are perfect examples of cargo cult and your comment confirms it. Just because some successful company adopts a technology it doesn't mean that it suits your needs. You could have completely different problems and adopting those solutions can be in the very best case useless and in all the other cases harmful. You need to adopt a solution because it fits your problem, not because "the most successful companies in the world" are using it. It's always a good thing to know that these technologies exists and what are they used for, but jumping on the hype wagon without understanding deeply the original problem that they solve, how the solution works, and most importantly if it applies to your use case trying it with some representative, real work in your project, it is a sure recipe for failure.

I agree, I thought the article was kind of BS-y until it got to the example section which I thought was spot on.

It would be one thing if we just knew these companies used these technologies, and that was it. Instead, we have conference talks, testimonials, and evidence that they are working well for them.

Obviously you should not use a technology without understanding it. Does this really require a discussion? No one is on the other side. But going "Well that technology is just hype" isn't understanding it, it's dismissing it.

Conference talks, testimonials, etc are often biased towards the positive. It drives me nuts when someone tells me why I should use some technology, without telling me why I shouldn't use it, and what its constraints and limitations are. Those are equally as important as the features. Project documentation are the worst at this, painting a rosy picture of how the tech will solve the world's problems, without telling you the practical realities of using it.

Right, because there isn't a litany for what could go wrong with every single technology mentioned in this article already...

Let's not pretend like there's a single technology out there that isn't constantly under fire.

If you strip out the strawman argument against each technology ("Let me tell you a story about how this technology didn't work in my imagination") you end up with one single premise - do research before adopting tech. Did you need to be told that? I think if one single person is making tech stack decisions in production and no one is going "uh can you justify this" you have far more serious issues.

No I don't need to be told that. That's my point. Most tech products make it difficult for me to do my up-front research, because they want to paint a rosy picture of their product to drive adoption. But I'm less likely to adopt it if I can't easily understand its constraints, failure scenarios, scaling bottlenecks, maintenance headaches, leaky abstractions, etc.

Can you name a tech product that is hard to research in regards to its constraints or failings?

The React and Redux devs engage in more self-critique, and are more honest and open in the shortcomings of their approaches, than just about anyone I know of in web development.

From the author of Redux: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

From the official React docs: https://facebook.github.io/react/contributing/design-princip...

No, no! It's all just hype! Don't look at new technology!

Glad to see! Thanks for sharing. I hope this trend continues.

It's not only about programming: Facebook uses open offices, so MUST we!

This is not charitable to the comment you replied to. That comment suggested that looking at what companies have had success with is a no-brainer, and you interred they were suggesting "jumping on the hype wagon without understanding deeply the original problem that they solve". Here, I'll quote:

> You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it.

I think you're both saying the same thing. People should look at what others are doing, and analyze the suitability to their own use case. I think this is exactly what people do. I've never seen a tool choice postmortem that concluded, "well we only chose it for hype, and that was stupid". It's always a specific thing that you thought would work better than it did.

For example, I came away from a project quite burned by Angular 1.x. It wasn't that we chose it because of hype that it was a poor choice, it was that the directive system did not make it as easy to build modular components as initial prototypes suggested it would be. React was then interesting to us (though we never pursued it on that project), not because of upvotes on HN, but because it scratched that itch better.

I guess I just don't see this wild hype cycle that everyone complains about - I just see people trying to scratch itches they have, sometimes making the right choice, and sometimes making the wrong choice.