
Hype Driven Development - rbanffy
https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22
======
chx
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](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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
blowski
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.)

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

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

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

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

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

------
hkon
Everything new is bad.

Everything old is bad.

Finding the middle way is hard and makes you sad.

~~~
weekay
Goldilocks principle IRL is not easy

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

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

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

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

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

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

------
sundvor
Aka "resume driven development". :)

~~~
6t6t6t6
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.

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

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

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

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

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

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

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

------
fidz
[https://hn.algolia.com/?query=https:%2F%2Fblog.daftcode.pl%2...](https://hn.algolia.com/?query=https:%2F%2Fblog.daftcode.pl%2Fhype-
driven-
development-3469fc2e9b22&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

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.

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

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

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

------
faragon
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 :-)

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

------
peter_retief
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 :)

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

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

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

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

~~~
electric_sheep
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...](https://medium.com/@dan_abramov/you-might-not-need-redux-
be46360cf367)

From the official React docs:
[https://facebook.github.io/react/contributing/design-
princip...](https://facebook.github.io/react/contributing/design-
principles.html)

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

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

------
skrebbel
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!

------
adamconroy
I call it TDD. Trend driven development.

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

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

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

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

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

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

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

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

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

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

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

~~~
altstar
How do you know what is best of breed development?

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

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

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

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

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

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

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

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

