Hacker News new | past | comments | ask | show | jobs | submit login
Hype Driven Development (blog.daftcode.pl)
202 points by rbanffy on Apr 22, 2017 | hide | past | web | favorite | 130 comments

There's one more and one much bigger: we need to scale our database horizontally and it's bastard cousin, we need the cloud to scale. Truth is, most applications are fine with a single box (OK, two because of HA but the second is just a hot spare). Remember https://twitter.com/garybernhardt/status/600783770925420546

> Consulting service: you bring your big data problems to me, I say "your data set fits in RAM", you pay me $10,000 for saving you $500,000.

Today it costs less than $600 a month to rent a 256GB dedicated box w/ 2x450GB NVMe disks and a 10 gbit private connection. And, of course, there are ways to go higher but it's very likely it'll be a bit more expensive per terabyte RAM but you'd be surprised (or not) at just how many problems actually fit in a quarter terabyte of RAM.

My manager told us $200/month was too expensive, so we micromanaged those $10 VPSs. We've reached the limits of that in some way. Instead of testing my original suggestion, my manager wanted to contract a company to move us to AWS. Our first AWS bill, for effectively zero usage and just a dev environment, includes $500/month for "NAT Gateway Hours".

You mean, like Hackernews?

Well at least some time ago this site ran on a single box.

My company has a Magento webshop. The amount of money thrown at it to keep it 'fast' is amazing. Wish they trew it at me to build a fast webshop. Unfortunately they think Magento is the standard.

No, I mean only the database. You might or might not get away with the app also running there but most of the time some load balanced 2-3 small frontends will give you much better buck for your money.

> Today it costs less than $600 a month to rent a 256GB dedicated box w/ 2x450GB NVMe disks and a 10 gbit private connection.

Any recommendations on how you'd go about that? I'm currently paying Digital Ocean that much for a way crappier instance...

OVH for instance has good options here: https://www.ovh.com/us/dedicated-servers/hg/160bhg1.xml

Yes, I was thinking of OVH, specifically https://www.ovh.com/us/dedicated-servers/infrastructure/170e... this one. Hetzner has one much, much cheaper https://www.hetzner.de/ot/hosting/produkte_rootserver/px121s... . But if you want to get feature parity, you'll need to factor in the additional 10 gbit card cost for 45.38 EUR arriving to a 174 USD monthly cost and the once off cost of a 12 port 10 gbit switch for 839.50 EUR. In five months the Hetzner server will be cheaper and keep going and also adding web frontends is cheaper there as well, the old but totally servicable Intel Xeon E3-1245 V2 16GB servers are below 35EUR.. But, I didn't want to get into that much detail.

Sincerely, this is compelling but not satisfying

Because old solutions are so old and boring. I've built programs with J2EE, I wrote those XML files. Nothing wrong with that, this stuff works. But it's so much better to write 2 lines of Kotlin code running a top of Netty instead. Yes, it's very immature and new. But having fun is essential in my work. If I'm getting bored, I won't work, simple as that. I could be a uber driver, if I wanted boring work. Some people are just boring money makers without any passion. Nothing wrong with that, but not everyone is like this.

> If I'm getting bored, I won't work, simple as that. I could be a uber driver, if I wanted boring work.

This is big problem in the "new economy" of automation. Some people want "boring" jobs and those are disappearing, some people want "stimulating" jobs and there's not enough of them or at least the threshold is too high to get such jobs.

Are you trying to say that Kotlin is better than J2EE & XML? Why not comparing apples to apples?

I think all he's saying is that there are jobs that you can solve either with JEE & XML or with Kotlin, and that for those choosing Kotlin is often the more efficient thing to do.

I'm more in the Spring camp, but most of JEE is annotations based. You can put a Betty backing under it without much problem. Spring Boot does it even more readily.

I'm not saying that Kotlin is bad, but most things are now pretty equal. Java 8 has functional/OO hybrid. It has annotations. It has modern tooling that converts the boiler plat into a few keystrokes.

Fair enough. I've been absent from the Java ecosystem for quite a while, so have no opinion or anecdata to share. It's good to hear though that there are multiple, sane options available to get stuff done.

I suspect that hype in the industry is at least to an extent something of an unavoidable side effect of hiring based on apparent enthusiasm.

Hype is worse that what people think: it create bubbles where constructive disagreement and criticism are quickly shunned.

Amazon has (or had) a culture of encouraging criticism (as long as it's supported by reasonable explanations) to the point of harshness and this was quite effective at stopping hype.

Grumpy engineers loved it, starry-eyed ones got hired elsewhere.

> Hype is worse that what people think: it create bubbles where constructive disagreement and criticism are quickly shunned.

And sometimes constructive criticism is mistaken for hype and shunned by the management, you would hear: we always done it this way, why choose this new technology that might break things; so you have companies that are still using COBOL on the mainframes and don't see anything wrong with it, as well as store user passwords unencrypted.

How many of you migrated web projects like this:

1) JQuery/JqueryUI

2) handlebars/mustache

3) Ember/Angular v1

4) React/Vue/Angular v2

From the average HN stories and comments over the last few years, this was the common path, and migration steps.

So I agree with the blog post in general (not the details). Instead of running from one hyped tech next and rewrite your stack constantly as a side-effect.

I value educated decisions and more long term thinking. Using Javascript and copy&pasting some functions from JQuery and other libraries to build one own/company little library/framework that suits the task might be a better idea. In the end the tech behind popular framewoks is often pretty simple and just a few lines of code. The hundreds of opinionated API corset around is what makes it hard to refactor and migrate later.

I think all of this serves to highlight how valuable information technology is right now. People can get away with massive inefficiencies, producing tons of garbage code, not-invented-here habits, horrible performance, and still run a profitable company. I agree that hype-driven development is bad, but instead of complaining about it, just don't do it. Run circles around those who do.

I have my own theory about why hype-driven development is prevailing: it's social signaling. Probably none of the hyped up stuff is as good as they claim, but nothing is cool without hype. It's a good way to attract younger developers in job postings, who lack the experience to evaluate their own career decisions.

I'm also not sure about the solutions proposed. Spikes and hackathons are useless if it's already determined that a hyped technology will be used, then it just serves as a training exercise. A strong technical background and experience comes with age, and this industry is heavily biased against older programmers.

> instead of complaining about it, just don't do it. Run circles around those who do.

...until employers start asking you to work on every buzzword of the month.

> A strong technical background and experience comes with age

No. You can be aware or unaware of hype at any age and experience.

>...until employers start asking you to work on every buzzword of the month.

This is absurd. Do you do everything your boss tells you to?

It's incredible that some employers survive long enough to chase the next fads, which only proves my point.

> This is absurd. Do you do everything your boss tells you to?

Ultimately, if I want to keep collecting paychecks, I kind of have to. You can only push back on dumb ideas so much, sometimes you have to let some of the less dangerous ones through, or you get labeled as the cranky pessimist douche.

Not all jobs are like this. I hope you find better bosses

Some of this is due to the immaturity of our industry. Even the most grizzled, experienced web developers typically have about 20-30 years experience. Most have fewer than 10. So we make mistakes out of immaturity and inexperience, rather like the junior blacksmith taking over the forge because there's no one else to do it.

Developers want to do new things, partly out of boredom, partly out of fear of becoming stale. Non-technical business managers have no idea of the consequences of "using Elixir instead of Java" or "Microservices instead of Monoliths" so they just nod and go along with it.

Eventually, developers get tired of having to pull all-nighters that could have been avoided by using more simple solutions. Then you have a bigger pool of 'experienced developers' who prioritise stability over fashion.

So the industry is becoming more stable and less hype-driven, but it will take a long time to get there. We need to learn lessons from other crafts and industries, like factory production and carpentry.

I have been programming since the '80s and I disagree that the industry becoming more stable or that the prime cause is immaturity.

IMHO the ultimate source of instability is that we deal with pure thought-stuff that has very little internal constraint except at the interfaces. Other engineering is quickly constrained by materials, biology and physics but for us, any idle thought can become our reality. The faster we can communicate and the faster we can build, the faster the iteration.

We can achieve much the same ends in any number of different styles and paradigms. The primitives for a programmer have more to do with poetry, memes, fashion and the creative end of pure math than physical systems. There can be no assumption of convergence. The pull of a social group will crush the technical excellence of an out group.

We face a lot of those constraints as well - money, time, computing power, knowledge, politics. In the short term, a social group may dominate and push a company in the wrong direction. In the long term, that company will lose out to the one that chooses the right direction, because of those constraints. ('Company' is a loose term here - it could be a department, a team, etc.)

Those constraints are incomparably looser than those encountered in a "stable" engineering discipline e.g. you can't build a driveshaft out of wood but you could write paxos in brainfuck. The use of physical material with hard constraints means there are "few good solutions" hence the disciplines converge and stabilise. Our thought-stuff just doesn't have that property. Even a hard real-time constraint does not strongly dictate many of our design and implementation choices of the written code, only the final behaviour.

Not being constrained by weight and size (unlike most other forms of engineering) explains code bloat and perhaps NIH but not hype.

The argument is that the lack of constraint means that social forces are allowed to dominate, such as hype, fashion etc. Its not causal, its vulnerability. Any human endeavour similarly unconstrained will see similar dynamics when popularity, status, boredom and novelty run free.

> 20-30 years experience. Most have fewer than 10

I've rarely met devs with more than 20 years of experience that would buy into any hype. OTOH it the most hype-y conferences I've been to the average level of experience seemed to be... between 0 and 2 years.

We developers have strong urge to try new things, new paradigms. Maybe it's FOMO. You don't want to stand in the corner, when it comes to those never ending debates, if A is better then B. I know what I'm talking about, It happened to me couple of times. We did rewrite our app from Backbone to React, the other one from Angular to React. Same story on the server side. Also I personally did poor job, be choosing NoSQL db over SQL db, which complicated lot of things later on. All this before we shipped anything. But I swear I will not allow to do it again. Enough on jumping on those hype trains. There must be strong tenable argument to do so, not just "hey, lets try this new stuff, because everybody is talking about it". It cost lot of money and users don't care about your tech anyway. You'll realise that, when you start throwing your own money to finance all those rewrites. It's really painful.

I know many more examples of decade-old, poorly designed not-invented-here-driven projects slowing velocity to a crawl. Teams adapting tools that are considered state-of-the-art in their field saves you from that road. Obviously you still have to make sane architectural decisions. The author misses the point, it's not at all about hype, it's about making uninformed decisions. They can be made about new or old technology.

"Loudest guy driven decisions — is when one guy is talking all the time about this new framework/lib/tech’s that he has no experience with, but talks about it all the time and finally the team decides to use it."

Except that this is how new technologies get introduced and tried. It's a completely normal process. The only thing to pay attention to is the track record of these guys -- if they're mostly right, then they might have a good intuition when it comes to new tech.

I worked with one of those, pushing Silverlight non-stop, it was like a year after it had been announced MS was dropping support for it. He was baffled when I told him.

Everything new is bad.

Everything old is bad.

Finding the middle way is hard and makes you sad.

Goldilocks principle IRL is not easy

It's not about hype, it's about understanding how stuff works.

True, you often see people jump into a new technology without understanding the tradeoffs and the implications.

However, a lot of people don't have a deep understanding of the non-hype systems either. Seems to me everybody expects SQL dbs to guarantee serializable isolation every time and everywhere, for example.

The list of sub-genres is missing 'consultant-driven development'. A good consultant is always ready to sell you the solution to his previous solution.

Many points in this blog post are spot on, The moral of the story is: There is no perfect tech stack or architecture, only pros and cons. The sooner you learn this, the better you become at making decisions.

The other moral is if you don't learn this you'll be a mediocre developer your entire career. But, hey, you'll get to play with all the new stuff.

"staying with the herd" (i.e: use technologies that are in active use/high demand) helps recruiting and retention, as well as benefiting from the collective work of the community around a technology.

"The big rewrite" is usually a response to technical bankruptcy, which is when technical debt and interest is too high to be repaid.

So true. Add Angular to the list. I would say, as a rule of thumb, if your team is not 5+ developers, don't bother using a framework. Because small team usually get small projects.

Aka "resume driven development". :)

Been there, seen that.

I some months ago, they asked me to join a new team because they needed help with React and, although my main technology is RoR, I quite like JavaScript.

What I found is that the last developer shoved 2500 lines React, Redux and Typescript in a Rails application just to make a sortable and filterable table!! Apparently, after perpetrating this atrocity, he updated his resumée and found a job in another company.

I really think that it is good to have a grumpy senior developer in each team stopping those things from happening.

With time the tools are getting better, and while rewriting existing projects is definitely a time sink, using new tools in greenfield projects is definitely beneficial.

Although it is true that microservices approach is flawed if it doesn't feet the organizational structure. But the same applies for the different new tools. Do the due diligence and figure out whether it fits before jumping straight into development.

I got a contract recently to build a small web app for internal use.

The client is obsessed with using Docker (he read about it somewhere). There is absolutely no way he needs Docker but we are going to to do it. Which is fine. But the real kicker was when he started asking me if it would be possible to integrate Machine Learning. He wasn't sure what for but do you think we could do it?

maybe just to stamp it with "Our product use AI/ML, so we're cool". But you said it's internal, that makes lot less sense.

I have seen two kinds of teams succumbing to hype,a team of novices who do not have experience/skills and are looking for a silver bullet to solve the problems. Second type is 10x developers pushed to leadership given a simple problem, to justify themselve they have to make simple problems into distributed big data problem, with some cutting age framework and database.

There is always the wandering circus, a rainshower raising flowers in the dessert. Wether the resulting bloom and dust leaves behind working affordable ecosystems- can be often determined by looking at similar situations previously down the line. Ask a old coder near you, what companys came to be from when he last saw thee - Enter Hype here -

Spring Framework is one of the biggest hype nonsenses for me. There are many other examples (SOAP web services, etc)

I agree somewhat with the article.

So many small/medium sized companies are obsessed with re-writing everything without even realizing that re-writing something from scratch is probably the worst business decision that can be made.


Apologize for my brevity, but i really wonder: this has been previously posted dozen times, but why it is popular now? I wonder if the time of link posting (morning/noon/evening) can actually determine the popularity of the post.

The guy uses contradictory examples to share his opinion. The second one, TDD, someone could do the same saying that it was hype. And then some maniacs will come to say it was not hype.

"Stack Overflow driven development" is the only way to go.

StackOverflow is fantastic. What is bad is to copypaste code from SO without understanding it.

HDD is commom in cases where the final word on software design decisions is on people not having a clue on what they are doing. HDD (Hype Driven Development) combined with IDM (Ignorance Driven Management) is the perfect combination for bubbles and raising and burning other's money, while selling "sky is the limit", etc. It's a miracle the world works at all :-)

My fundamental problem with this is that the steps he outlines are identical to the steps involved in successful adoption of game-changing technology, until we hit the "It's too late" phase. Indeed, whilst sometimes a technology just plain isn't ready for prime time, sometimes it's just the wrong tool for the job.

Not always a bad idea to try new and exciting developments (Bit of a time waster though) I like your examples, I remember the ror years well :)

bad examples.

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 also completely disagree that hackathons are good places to try out new technologies to see what's good for good engineering decisions; hackathons let you dip your fingers in the water and see the shiny cool bits and pieces without having to suffer through any of the long term maintenance or scale issues with the technologies. If you're looking for a bad decision, picking something to run with that 'seems pretty good' after a 2 day hackathon <--- that's your bad decision right there.

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

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

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.

Even if it means picking up new technology: that's not bowing to the hype; it's being pragmatic.

Still, it's super easy to cherry pick some things and go, oh hey, this is a bad idea. Much more interesting would be some examples of good engineering choices.

> 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?

>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.

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.

> 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.

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.

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?

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

> 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.

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.

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.

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...

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

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

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?

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

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

i think a lot of people mix up micro services with distributed systems. two different services for example the smtp service and the http service should not need to communicate internaly. they should be able to deploy independent of each other.

As someone who does a lot of web frontend programming, I really love that Node.js has been such a hype.

I hardly ever used Node for something other than frontend build chains and tooling, and it works like magic. It's all in a super familiar language and the ecosystem is fantastic. Thanks, hype!

I call it TDD. Trend driven development.

The flip side is brushing off everything new or unfamiliar as just hype.

Everything we use now, all our old shit, once upon a time was the new hotness. So, were the people who used it then going off of hype? When did the decision to use Java (for instance) switch from being hype to being wise? At what point is the reaction "ah yes, this person made a wise decision based on their deep understanding of the right tool for the job" instead of "you just like shiny things" and eye rolls? Perhaps sometimes people choose new technologies because they understand the potential and they don't think everything we have today is necessarily perfect.

It seems that for most, the answer to the question I posed above is: everybody who switched to the thing I like before I did is a hipster. Everyone who switched after I did is a dinosaur.

I agree. Not every switch is hype motivated. But one must be very careful and stay rational in making switch decisions.

When people criticize "NoSQL" databases they always conveniently forget the high availability part that most non-relational databases provide. When I need HA, I'm going to chose something like Cassandra, not MySQL or even Postgres.

Is this satire? If not, that's a superb example of HDD.

You need HA and no matter your other requirements, or the ability of modern RDBMSs to scale up and cluster out, you're going NoSQL. Sorry Postgres, MySQL... You power some vast systems but you're just not webscale enough for Sphax here :)

On a serious note, scaling and replicating and clustering aren't trivial topics (yet) because there are so many different ways of doing it, to fit different performance profiles.

But it can be done. It can be done well. If a large HA database is a core part of your product of company, hire somebody who knows about databases to do databases.

It isn't satire, and I fail to see how what I said is HDD. I haven't mentioned the word scale once, that first paragraph is out of your imagination.

I worked with PostgreSQL, work currently with MySQL and Cassandra. With Cassandra you get HA out of the box, with PostgreSQL and MySQL not so much.

Your last paragraph is true, except most company can't afford that.

Your requirements might be perfect for Cassandra or another NoSQL engine, I'm not here to fight that.

It's the unwavering, front-line suggestion for NoSQL that I consider HDD. There was tons of this after Mongo started getting popular. But it's suggesting a satsuma as the best type of apple. Yeah, NoSQL does some stuff well, but there's a pile of things it doesn't handle at all. It's not a drop-in replacement and people treating it as such have wasted so much developer time trying to turn it back into a relational database.

HA isn't a feature exclusive to either type of database.

How much money do you lose (say... per second) when you have a minor (few seconds) of service interruption when switching to a hot fail-over RDBMS and waiting for it to be promoted to master?

We don't bill per second, so this really doesn't apply. Our customers see it almost instantly if we're down though, so it matters a lot.

Besides, that switch you're talking about just doesn't work out of the box. We never had any success with failover on our Galera cluster. Now, I'm not saying it's not doable, because I'm sure some teams have this work flawlessly. My point is that with Cassandra, it works out of the box without problems.

If you can't measure the actual impact, or don't know it, then it's hard for me to believe that it matters in any other terms than you'd really like it to matter.

For instance Twitter going down would be annoying, but global air traffic control going down would "matter".

Which I think might somewhat align with the original article's sentiment. Part of the hype cycle is driven by a hubris that we often engage in. Which is that we want our problems to be bigger and more important than they might actually be.

You're free to believe it or not, fact is our customers require that uptime. If that requires me to use some "hype" technologies then so be it.

Yes, and the high availability part becomes important long before "Scalability, BigData, High Performance", because a typical one-two nines availability that you get with an architecture based on a traditional RDBMS just doesn't cut it anymore on many (most?) markets. From an infrastructure perspective traditional RDBMS is not a smart default choice.

The article is either trolling for views or the author is in no position to speak about databases.

Which markets can't tolerate only having a couple nines of availability?

Galera is a thing, and ships "out of the box" with mariadb cluster and percona cluster.

The only feeling that this post gave me is: "Get over it. If there was no HDD you would still be programming assembly."

If you don't want to bet on new technologies than don't. No harm done. It is like the startup world, you don't want to invest? Don't! You do want to? Do! Of course the people who take the risk have also the benefits of getting the early gains. most big digital companies took a bet on new technologies to be the first on market. Sure, it had to fit your needs, but who says hypes can't?

Such garbage.

ReactJs is a great way to write software. I'm far too time poor to waste my time on "being cool". I choose best of breed development tools that are well supported and allow me to be highly productive.

Only a fool would suggest that ReactJs is simply a hype trend like s new hairstyle.

I don't know your use case, but my experience tells me that people uses react in places where it is absolutely not necessary.

Having state both in the front-end and in the back-end multiplies the complexity of any project, and the gains are only worth if you are (or you have) a good UI designer.

For the rest, the good'ol Rails + Turbolinks, jQuery and SJR can do a fantastic job, without having to think about synchronizing several sources of truth.

You can substitute react with php, Ruby on Rails, angular, meteor. They are just hype cycle that periodically bubble up. This doesn't mean that in a lot of use cases they are the right choice, but denying the hype is like saying that the sky is not blue.

How do you know what is best of breed development?

I do a lot of research and choose tools to suit my tastes.

Same here, we investigate literally everything from Angular (1,2), React, Vue, hell even using just pure JS for a month and settled on React. We never looked back. Developers are happy, CTO is happy, client is happy.

I guess this article is trying point out how people chose things based on hype but fails to understand the difference between choosing X because of hype vs. choosing X because it suits your needs.

> I'm far too time poor to waste my time

To paraphrase Peter Hellier: if you stopped using extra words when one will suffice, maybe you wouldn't be.

There seems to be this group of developers who love nothing more than to rubbish the design choices of other developers. As though they are in a better position to judge (a) what is risky or not and (b) what is suitable or not. And often those developers are those who haven't really done anything all that impressive and often lack broad experience.

The idea that React is not a suitable choice for front end development is ridiculous. It has a lot of mindshare, is popular and has a major backer. The idea that Microservices demands significant DevOps effort is ridiculous. You can literally just duplicate your Jenkins jobs. The idea that NoSQL has no use case is just laughable given how successful DataStax, Hortonworks, Cloudera, MongoDB etc are all doing. They all serve legitimate use cases at a price infinitely cheaper than Oracle or Teradata.

Before you criticise other developers: STOP. And ask yourself if you are genuinely in a better position to make their decisions for them.

To me it seems even more ridiculous that react is the silver bullet for frontend development. Or even more laughable that microservices don't require a considerable devops effort. Each tool has its use cases. Using react for a small page mostly static or using micro-services for a use case that doesn't require them is just plainly wrong. I don't agree completely with the blog post about HDD (that actually is known as cargo cult), but I completely disagree with you that are trying to sell react and micro services as THE solution to every problem.

> To me it seems even more ridiculous that react is the silver bullet for frontend development.

For me (and other Clojurescript developers) React is one of the best ways to do front end development. Simply because of it's virtual DOM concept, which allows us to hot reload parts of the page as we write new code. Just save the file and the page updates. It's incredibly productive, and a development experience I've not seen replicated elsewhere.

Virtual dom has nothing to do with hot reload. Ages ago (more than 20 years ago) you could do the same while writing HTML and refreshing the browser. And if you used WYSIWYG editors it was even mostly unnecessary.

Hot reload means something different than refreshing the page, automatically or manually.

If the state of art of your development cycle is refreshing the browser, check out hot reload.

Refreshing the page is what you currently have to do with a typical javascript setup, with the main problem being that you lose all your state on the page. For example any form fields you've filled out. With bigger Web apps this can be quite a slow way to develop.

WYSIWYG editors are built very specifically to convert to and from from a particular markup to html, they can't process anything outside of that.

Clojurescript and React allows me to make changes to part of the DOM and only that part of the page updates, maintaining state on the rest of the page. This is made possible because of React's virtual DOM which can run a diff algorithm and only push through the parts that have changed to the actual DOM.

Is it the best for your product or your customers. In your case it may very well be. However, you CANNOT[0] make tech stack decisions solely on how easy it is for YOU.

[0] Should not.

Clojurescript compiles down to regular Javascript, and React is used by Facebook which is in the top 3 most visited sites in the world. So what's your point?

That most developers won't be building a top 3 most visited site in the world. FB's needs are not necessarily everyone else's needs. React may or may not be a good choice for any given project.

I am pretty sure I made my point clear. What is good for a developer isn't always good for the customer.

I have never said those tools are suitable in all situations. I also don't believe that I should be lecturing others about which tools to use. If they think React is better for their use case. Great. If they think Vanilla JS is better for their use case. Great.

But people need to stop posting this garbage and dismissing their legitimate choices as "hype".

You're misreading the blog post. Choosing React because it's a well-engineered solution to a specific type of problem that plagues front-ends is fine. Choosing React because it's currently the most talked-about and blogged-about platform for front-end development is not, and is likely to lead to issues.

Similarly micro-services. If you cannot see the tradeoffs you are making when you choose to use them, you will blindly lose man-years of productivity when you inevitably encounter their rough edges. Prepare for them, and work around problem areas like monitoring and interface complexity, and it may be the right choice.

This is nothing but strawman arguments with zero factual basis.

Who are these mythical developers that are selecting technologies purely for hype ? Are these developers so significant in numbers than it is undermining our industry and causing projects to fail ?

And if choosing a technology because it is talked about and blogged about is bad a thing. Then is choosing an obscure and abandoned technology good ?

So many questions.

There are plenty of blog posts there in the wild about people adopting one hyped technology and after much pain migrating to another one that was a better match for their problems. If you don't know anyone in that situation first hand maybe you didn't change enough jobs or you are very lucky, because I assure you that it is quite easy to know someone with this kind of experience.

There are also plenty of blog posts about people moving from c++ or java to hyped technologies. Or blog posts about people failing horribly with matured technologies. Today's hype seems to be complaining about other people's hyped choices. You can't know all the reasons that made people select a technology unless you were there. Generalizing them into a group of people that make hyped choices they will regret is nonsense. Could have equally happened if they chose a non-hyped technology because most likely you go on incomplete information anyway.

So we can either summarize authors post with "don't make choices without thinking", which is kicking in an open door, or "let's blame people for choosing hyped technologies", which is no better.

> Before you criticise other developers: STOP

That's exactly what hype is: not using enough critical thinking and trusting developers of popular technologies.

>> Facebook promotes new paradigm with buzzwords: functional, virtual DOM, components.

In this case, Facebook please keep going, we need more promotion of buzzwords like for example "functional" in tech.

Seriously though, these guys are either trolling or they have absolutely no clue about how to decide what is good and bad in technology. Sounds like a grumpy old man, everything "new" must be bad.

Just for the record:

"Functional programming has its origins in lambda calculus, a formal system developed in the 1930s to investigate computability, the Entscheidungsproblem, function definition, function application, and recursion."

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact